Very interesting work! I think that one might (naively) have expected the `Location` to be exposed as a `Sub Location`. One could, then, use the sort of `Parser` which you provide for (to `map` the `Sub Location` to a `Sub msg`), and then supply the `Sub msg` when initializing the `Program` (as you might with any other permanent subscription).
Instead, the module provides for a different way of constructing a `Program` -- that is, an alternative to `Html.App.program` or `Html.App.programWithFlags`. What this permits, at first glance, is providing for an entirely separate function to handle updates from navigation -- that is, a `urlUpdate` function which is separate from the usual `update` function. (The naive approach I mentioned above would only have an `update` function, with the location changes mapped to messages that the `update` function understands). What problem does a separate `urlUpdate` function solve? My guess is that it solves a circularity problem. Consider (as in the example provided) incrementing or decrementing a counter. In the `update` method, in addition to updating the model, one wants to issue a command to change the URL. In the `urlUpdate` method, you just want to update the model. You don't want to change the URL, because that would trigger another round of `urlUpdate` -- you'd be in an infinite loop. So, the separate `urlUpdate` function is a kind of a reminder not to issue further commands to change the location inside the `urlUpdate`. (Or, at least usually not -- I suppose there might be some scenarios where you might actually want a kind of "redirect", so long as the redirecting terminates eventually). So, that's an interesting solution. Are there any disadvantages to it? I suppose that there are a couple of potential disadvantages. One, I suppose, is a question of composability. This strategy is kind of a singleton -- at least, it's hard to see how you could use this strategy again, and then compose the two. But, perhaps you won't need this strategy again, or you'll figure out how to cross that bridge when you come to it. The other potential disadvantage is a kind of duplication between the logic needed for `urlUpdate` and `update` -- both logic in the sense of dispatch to sub-components, and logic in the sense of the logic for the actual model changes. Though, I suppose that problem is relatively easy for clients of the library to solve -- one could imagine a third function, `universalUpdate`, which takes a `Bool` parameter that indicates whether the change is coming from `update` or `urlUpdate`. Then, both `update` and `urlUpdate` can call `universalUpdate`, which would know whether to change the URL via the `Bool` parameter. Or something like that -- it seems like a solvable problem for users of the library. I suppose that is how one could solve the circularity issue in the "naive" subscription approach as well. That is, one might include, in the `Msg` type, an indication of whether the `Msg` is coming from "normal" user action or from the URL change. (And, thus, know, within the `update` method, whether to issue a URL change command). Anyway, I hope I have not offered any opinions in the above comments -- I don't really have any opinions yet, just a few interesting things that I noticed. -- Ryan Rempel On Wednesday, May 25, 2016 at 5:02:03 PM UTC-5, Evan wrote: > > On Friday, Noah and I worked on "updating elm-history" so that folks can > do "routing" with Elm 0.17. The results are these libraries: > > - elm-lang/navigation > <http://package.elm-lang.org/packages/elm-lang/navigation/latest/> > - evancz/url-parser > <http://package.elm-lang.org/packages/evancz/url-parser/latest/> > > I think they will cover the core functionality in a way that also promotes > healthy architecture. If you disagree, I ask that you *use* these > libraries before you share your opinion (or ideally the particular scenario > you are having trouble with). > > > Details > > The elm-lang/navigation library is the core thing. It lets you get > notified about changes to the address bar. This may be the user typing in > there or pressing the forward and back buttons on the browser. It also lets > you "navigate to new URLs" so you can go to new URLs without reloading any > assets. > > The elm-lang/navigation library is designed such that you can parse URLs > however you want. You can see a basic example of that here > <https://github.com/elm-lang/navigation/tree/master/examples>. The > evancz/url-parser library is meant to handle more complex cases. You can > see a bit of that in this example > <https://github.com/evancz/url-parser/tree/master/examples>. > > My URL parser is intended to be a baseline for exploration. There are > probably cases it does not cover well. My goal right now is to point us > towards good API design, not to be *the* URL parser. > > > Thanks > > Big thanks to Noah for working through all this with me! And thank you to > Aaron who helped review and talk through the API we ended up with. These > were fun to work on :D > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
