slush-marklogic-node
slush-marklogic-node copied to clipboard
marklogic-community
Search state not preserved
Moving back and forth between search and create, does not preserve earlier selected facets, and such. Should be possible to preserve that in memory, until someone reloads the browser..
I think we voted to replace url params with keeping state in memory, but looks like that got executed only partially..
Is there a record of that decision somewhere? I feel like deep linking is pretty important.
On second thought, could be something 'simpler', like an (ng-)href to /search without request params, or in the newer approach a state reference that won't recover the earlier request params, so reading them fails?
I feel strongly about deep linking too. Would rather that be on the url than in-memory.
Can we get a test case or detailed description of the circumstances under which the search state is not preserved? The current search controller inherits from MLSearchController, which automatically handles URL params. Any cases where the search state is incorrectly lost are bugs in that prototype controller.
Very simple to reproduce. Generate a vanilla app from the latest slush on github. Deploy and load sample-data. Go to search, and click a facet value. Then go to Create, and back to Search. Selected facet is lost..
Then go to Create, and back to Search.
Go back how? By clicking a static link to /search? Hitting the back button?
I rarely use the back button of the browser. I simply clicked 'Search' in the header. Not sure what kind of link that is. I thought a ui-ref..
To be clear: I am not against displaying those request params. But it should not be necessary to use them to recover search results and filters that you had available in angular a minute ago. All those redundant calls to ML can really kill the performance of the app.
I see what you're saying @grtjn . Basically execute a search and hit another tab (think mobile apps) and then you go hit search (which routes to /search) and now to have to search again. So basically you want to save the search state if you click away from search.
Honestly not sure if that's the general behavior of most web apps or not..
It is actually very simple to do. Keep in mind this really is a single page app. Just stick the search context in a singleton (an angular factory for instance), and restore the context whenever the ctrl gets reloaded. Have been doing that in pretty much all my demos, and also demo-cat for instance..
The question is, should that be the default behavior? I like resetting the context when I navigate to /search, and I think it's how most web apps behave.
I think users will want to be able to choose. If opening a search result, one likely want to jump back quickly to view another. Coming back from another page could depend on user expectation. So maybe we need two buttons. In my demos i typically used the logo for an oldfashion reload with href="/", and Search link preserving state. I'm open for other suggestions.
I do think it to be easier to flush context than to recover it. Particularly if you have lost the info..
You could make it that by default it takes you back to the last search. If you press search while on the search page (not viewing a result or anything) it just flushes all of the search params.
Not sure that is as easy as it sounds, but does sound interesting.
@jenbreese What is your view on when search state should be preserved and when not, and how you think a user would expect to clear search?
Can we get some more clarification on thoughts for this?
After some research, it seems that the implementation seems to use a service to keep the search when swapping between routes.
My current behavior thought is do as a I said previously. When on a different route and the user presses search (note if they don't actually reload or use a new tab) they will be taken to the previous search. Similar to if they had pressed the browser back button. However if they are on the search route and press search it will reset search.
My reference (also used if we never had persisted route params): http://stackoverflow.com/questions/12940974/maintain-model-of-scope-when-changing-between-views-in-angularjs
I personally like using the Search button that way.
Just as a reminder, it is also important to not make unnecessary round-trips to MarkLogic. You could recover state by repeating the search from parameters, but that will make a demo app respond very sluggishly..
Regarding the ref: yes, $rootScope is one option, service/factory/provider another. I choose the latter in my demos, because it allows isolating the per-ctrl-models more nicely..
Can I just move the search context onto service and that way it has the results and all? Also do we show any indication of when search occurred? Just in case you expected a new search and none happened or otherwise.
Users always love some feedback. A tumbler while it is making a backend call would be nice, but we have been doing without that for pretty long already.
I'd be fine with putting the state/context in a service. I typically had a factory in the same file, for instance for a SearchModel to go with SearchCtrl. Not sure if you were thinking more in terms of a store kind of service. Whatever feels right to you.
Just make sure it won't bite with param setting/parsing from ml-search, we want to keep that to make deep linking easy..
Should this still be a bug? I feel like we've now determined the desired functionality needs to be settled on.
Hmm, was in doubt, but the current status is that if you go from search to detail, and back to search by clicking the Search on top, search state is not recovered. That only happens if you use the browser back button. I don't think we should depend on that.
Anyhow, the proposed PR was pushed back, so pushing this back as well. We have a solution if people ask. We can think more closely about the issue and possible solutions later..