> > Is there any reason to favour one over the other, otherwise I'm likely to > go with 2.
Yeah, I would say stick with option 1. Our large SPA in elm has used option 2 for the past 5 months, and we've recently swapped over to option 1. Here are some pros & cons: Option 1: Pros - Embraces the browser by creating real clickable links. I can CMD + click on a link and open it in a new tab, I can CTRL + click and open it in a new window. - Easier to implement in Elm (not necessarily better, just easier) compared to option 2 - Easier to maintain to understand. - Routing state does not need to be stored in the root model. This is tough to explain. Using option 1, If someone navigates to "/apples/234" in your elm app, your app would parse that url and generate a Msg like "AppleRoute 234", send the msg to update func, fetch the "apple" resource id=234 from the backend server via http, and use that data to display the "ApplePage". Done. Although we needed id "234" to load the apple data, there is no reason for us to store that id in the root model of our application - After it's been used to load the page, it can be discarded. Not so, however, for option 2. You're forced to store that ID in your root model so that you can derive the address bar url from it. Cons - Even though it is easier to maintain, read, and write (hahaha) I strongly dislike one aspect of option 1. Why should I use the browser to pass messages around my app (click an html link > the browser updates the address bar > elm root receives url change msg) when elm can pass messages internally just fine. Arg... Option 2 Cons - Lots of msg translating and indirection - There will be a healthy amount of upward messaging from child to parent (notify root that a navigation link in the child was clicked). I wouldn't recommend this to anyone just getting started with elm, but if you already have experience with elm, go for it. - You need to store routing state in the root model, specifically for the address bar representation. - Links in your html view will not be real href links, so you lose some functionality mentioned in the option1 pros. Pro - All aspects of the application are driven by elm. The internal messaging is done in elm. Address bar changes are driven by Elm. You could easily swap this app to a different platform (anything that is not the browser), make a few changes to your view layer, and blammo - the app would run. On Friday, November 25, 2016 at 11:22:01 AM UTC-5, Simon wrote: > > Erik, > that makes such a lot of sense. Thanks for spelling it out. Is there any > reason to favour one over the other, otherwise I'm likely to go with 2. > Simon > > On Friday, 25 November 2016 16:52:20 UTC+1, Erik Lott wrote: >> >> When you're creating an SPA in elm, you'll generally need to choose one >> of two navigation styles: >> >> *1. Allow the address bar to drive your model* >> The standard Navigation package provides this type of functionality. Your >> model will respond to changes in the address bar, and your views will >> (generally) use view links (a tags) to change the address bar. You may have >> a few sprinkles of manual url changing commands throughout the app for >> redirection, but for the most part, the majority of url changes are caused >> by users clicking on html links in your view. >> >> The changes flow like this : View --> Address Bar --> Model --> View >> >> *2. Allow your model to drive the address bar* >> In this case, the address bar is simply a reflection of the current state >> of your model. There is no need to update the address bar manually, because >> it will keep itself in sync with your model. Try using a routing package >> like Elm Route Url ( >> http://package.elm-lang.org/packages/rgrempel/elm-route-url/latest). >> Take a moment and read the package readme. It clearly explains the >> difference between the 2 styles of routing. If you use this style of >> navigation, you'll need to build your application in such a way that the >> navigation is kept within elm and does not require the address bar. For >> example, rather than including a tag links in your html view to change the >> url directly, your a-tags or buttons will trigger Msg's that will update >> your model, and then the address bar will respond to the model change. >> >> >> >> >> >> >> >> On Friday, November 25, 2016 at 4:32:50 AM UTC-5, Simon wrote: >>> >>> OK, I just don’t quite understand, even while I have working code! >>> >>> I have an app where, as the model changes (in particular the value >>> representing the ‘page’ of my single page app), the Url is updated with >>> this task >>> >>> Navigation.newUrl (toUrl model) >>> >>> But as the Url changes, I get a new message from Navigation because of: >>> >>> main = >>> Navigation.programWithFlags >>> (Routing.urlParser RouteTo) >>> { init = initWithFlags >>> , update = Routing.update >>> , view = view >>> , subscriptions = subscriptions >>> } >>> >>> When first loading the app, this message is useful and I can use it to >>> direct to the appropriate opening page. But thereafter this message is >>> redundant - I already made all the model changes I wanted before and that >>> caused the Url update. Without some care I even get a loop of each Routing >>> message causing the >>> >>> *I suspect I am missing something rather important, but am not sure >>> what?* >>> >>> One option would be to use anchor tags to cause the switch pages, and >>> only do model changes when I get a RouteTo message, but even then I >>> have some url changes resulting from the clicking on an element within a >>> page, and I don’t think that is a place for anchors. (As I use html urls, >>> rather than # ones I also have to be careful not to let the page get >>> reloaded) >>> >>> >> -- 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.
