order matters in TabUnion's query about untangled-client HOT 6 CLOSED

Oops. Yeah, that's true. My assumption was that you'd initialize it the same in both places, so it would not matter. Since those are different tabs, why introduce order dependence when you can use different idents for the search results? That might make the search a slight bit more code, but it would be less subtle. At present, you compose the initial state (which is going to happen first, since you did it), and then others are merged in when they're detected.

I'll give it some more thought, and there is one thing I'd probably like to fix: the "default" of the union gets double-merged since the post-step re-merges all of the alteratives. I didn't figure this would be a problem since it should be idempotent. There is only one time in the entire lifecycle that these run.

from untangled-client.

I think if the implementation was merging the alternatives first, then merging the default, this would produce deterministic global atom & solve my use case. Consider that if you were trying to mathematically model this feature as a pure function global atom state = f( initial-state of Root, initial-state of all Unions ) it doesn't quite work because the global atom state is a function of the ordering of map entries in the union query expression and the order of map entries isn't suppose to matter either. If you merge default last, then it can be modeled as a pure function.

I could also have unique idents for each search results, but that has slightly different semantics: every tabs search results will exist in the global atoms state. As oppose to with 1 ident, :global, it's a singleton and old search results are overwritten with switching tabs keeping memory footprint small. I think it's worth allowing both behaviors to be achievable.

from untangled-client.

You are generating the app state with InitialAppState. That is the base state. There is no merge order...InitialAppState is the initial app state. So, the alternate initialization of the union branches is done as a convenience for you as a post-step (iff they have InitialAppState). Why can't you just drop the "initial" search results state from the alternates? It is meaningless to include it in more than one branch.

from untangled-client.

"Why can't you just drop the "initial" search results state from the alternates?" Great question I guess this gets to the heart of the issue that my initial-state is dual purpose: it also called by a mutation 'app/choose-tab i call initial-state to initialize the tab, so the :search-results :global gets initialized on tab switch. So yes there's definitely a lot of different ways of going about this. i.e. Using initial-state params to differentiate between the initial app state and the initial tab state.

I understand where you're coming from, i'm asking for a 'merge ordering' to be properly defined in InitialAppState, whereas you're striving for "no merge order". I can understand why my use case is not great. I totally accept that, but i'm still a little surprised you're 100% satisfied with the current implementation which can't be modeled as a pure function. "No merge order" doesn't describe the implementation. A description of the current implementation is better said as "if initial-state has merge conflicts, then results are undefined" I don't personally like undefined behaviour (specifically i'm talking about the ordering of the tab union query expression causing different global atom). Sticking with the reality of the situation, better solutions would be for example detecting this case and stripping out the merge conflicts, or resolving merge conflicts deterministically, etc, etc. If "There is no merge order" was an accurate description of the current implementation I'm all for that, but it's not.

Also I thought it was simple code change to just initialize the alternate tabs before the default tab (?) // the dual benefit being you don't double initialize default tab.

from untangled-client.

So, determinism isn't going to happen. You're going to have order dependence unless you do a lot of processing. If you refer (and initialize) the same thing from multiple branches, then the order of your map will matter. Simply saying that your "default" is merged last does give you a workaround, but it doesn't change the fact that there is the possibility of an inherent overlap: you're initializing a graph from multiple sources that can write to duplicate paths. If you do so, the behavior cannot be well-defined in any easy and general way (e.g. what happens when your map gets larger and the order of the map becomes hash based instead of order-of-entry based?). In your specific use-case I can see how you can work with it...but I'm having trouble getting motivated to do the work involved in providing for your use case given that it isn't a fully general solution (in fact, there isn't a fully general solution). You always have to understand what you're doing, and you can always make these kinds of mistakes.

I agree that your suggested solution does give a way to resolve such conflicts (default wins, if you manage to make sure any conflicts are covered).

If you want to send a PR to fix it, fine. I can agree it would be "nice". I simply don't have the cycles to dedicate to it.

from untangled-client.

Okay great, i appreciate the intention to accept a PR. This is also low priority for me, at the end of the day the API is still really good. If I do find some cycles i'll send a PR your way. Thanks for digging into this with me.

from untangled-client.