-
Notifications
You must be signed in to change notification settings - Fork 531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Path-based routing #42
Comments
This looks like we have the same issue #41 |
You can just define a |
Yes, that's what I've meant by introducing redundancy. There are pages that don't contain any logic and you'd have to implement all the updates and messages just for this purpose. |
Ah, I see the crux of the issue now. You want to allow the user to change the route from a reused section of the page, e.g. the navbar in the header. The basic problem is that On the first problem, one solution is to rewrite frame : (contentMsg-> msg) -> Bool -> Maybe User -> ActivePage -> Html contentMsg -> Html msg
frame tagger isLoading user page content =
div [ class "page-frame" ]
[ viewHeader page user isLoading
, content |> Html.map tagger
, viewFooter
] Now, So then second problem becomes how to get You could use essentially the same technique, which is also layed out in the Elm Guide on reusability: inject a msg constructor function, in this case frame : (contentMsg-> msg) -> (Route -> msg) -> Bool -> Maybe User -> ActivePage -> Html contentMsg -> Html msg
frame tagger setRoute isLoading user page content =
div [ class "page-frame" ]
[ viewHeader setRoute page user isLoading
, content |> Html.map tagger
, viewFooter
] * Or to be precise, Then you can pass this I haven't tested this, but in principle something like this should work. |
I've had to deal with the same problem a couple of weeks ago. @ericgj Your solution is great when we would only need to send messages from the layout. @mewa @ivanceras In the case of wanting to do path based routing, we need to do be able to send a "new url" message from every page, using a click handler with preventDefault. The solution I used is using Html Msg everywhere instead of using Html.map and calling the view with for example Html LoginMsg. For more info about this, see the NoMap way of doing parent-child communication: https://medium.com/@_rchaves_/child-parent-communication-in-elm-outmsg-vs-translator-vs-nomap-patterns-f51b2a25ecb1 Keep in mind, this requires a big rewrite. I'm still not too happy about the way it looks now, but it allows me to send global messages from everywhere in my app. If someone has a better architecture for this problem, would love to know more. |
@mewa I didn't run into these issues with dwayne/elm-conduit even though I'm using path-based routing. I think one of the problems with the HTML provided by RealWorld is that it uses links where buttons would have been more appropriate. In my implementation I use buttons where it calls for button semantics. Using @nimrev I'm using a form of child-parent communication that I'm calling "the dispatch pattern". See if that approach works better for you. |
Current approach works well when you have hash-based routing.
However if you want to use path-based routing, you'd have to prevent default link behaviour in order to avoid loading the page every time, which in turn requires either:
SetRoute
message of the root module somehow orHomeMsg
and the like are wrapping the other sub-messages at the moment)The text was updated successfully, but these errors were encountered: