Memoization

[nicklasb]

Loading long lists from a server may take a long time, a "caching"-property should be considered.

[ravivit9]

The factory.getData will take care of storing the promise for future use. First it will find whether a promise exists for the given request, if exists then it just returns the promise otherwise it will go and fetch from backend.

[nicklasb]

So If I implemented memoization, you wouldn't need it?

[ravivit9]

it might be useful for others as well. If you are providing that functionality that's also fine, in that case what happens when the drop down list data changes at backend, how will front end knows about that change. Say if I add an organisation via front end and if dynamic select memorised prior to this operation how does the dropdown knows there is a new entry in the backend and decide to pull from backend instead of from memory? What mechanism you are planning to implement to tell the dynamic select to check some kind of flag whether the data is changed then go to backend if not take from memory.

[ravivit9]

The way I did is any backend dependant data will have a front end edit screen for performing insert, update & delete. If any of this operation carried out I send a flag to the dataFactory.myFunc(); If the flag is true then the function assumes there is a change in the data then it goes to backend and fetch the updated data after which it resets the flag. So when next time i retrieve the record without any modification to the backend data, at this point the flag is false so it just returns the promise it returned earlier. By doing this we are not storing anything deliberately in cache but reusing the promise.

[nicklasb]

Well, this is a classic problem, where there are lots of solutions. My experience is however that it is not that big of a problem when it comes to drop down content. Usually it is oneself that adds the content, and then it can be handled within the client. An a page refresh is not a big problem, as it is not a frequent problem.

A bigger problem is that someone removes a option and you post a change with that option. But in those quite seldom cases, having an understandable error message from the back end feels adequate.

How specific is the change flag? is that per data type? If not, and your solution grows, with many users, it will be constantly true.

I have been working on windows-based systems that try to solve this perfectly. I mean that the user should not even be able to even select something someone else deleted a moment ago, and it is basically impossible to maintain.

To conclude, I am not after to have the server never be contacted to reload unchanged data. What I am after is the clicking back and forth that users do, that results in hundreds of reloads and a sluggish UX. Having just a 30 second cache solves 95% of that.

[ravivit9]

The section I am working on is only the profile owner user will be able to delete or add organisation to his own profile other user's will not see some other user's edit profile page. Any logged in user will see profile edit page only for their profile.

[nicklasb]

Ok.

There is this concept, action lists, that is quite heavily used in desktop applications, and it is a quite loose and flexible concept.

It is quite simply a application-central list of actions. It is used for almost everything.

I think it could be made into a central thing for managing stuff like this. Something the different components in the application could subscribe to, or watch. Or whatever.

One could then add an action-identifier(with an appropriate name) to each form field, or model. One could, for example, have a "organizationsChanged"-action, so that if anything, in the application, makes a change to the list of organizations, the organization-property could just have a invalidateOn = "organizationsChanged", and its drop downs cache would be invalidated.

That is very flexible in that it doesn't require any centralized data management. And of course, the actionlist could forward events from a server too, if one wanted to.

Or one could call it "event", "message" or whatever instead of action.

[nicklasb]

Caching will likely use something like angular-cache.
I am looking at starting a new project for managing caches and centralize event management:
https://github.com/OptimalBPM/angular-actions

[ravivit9]

Will read through the above link and let me update this afterwards. Been a bit busy past few days.