Thanks Simon, and the latter is exactly what I'm trying to do. However,
with the click handler in place my update function never receives the
UrlChange message. The only thing that comes through the update function is
the NoOp.
On Thursday, December 15, 2016 at 12:11:12 PM UTC-6, Simon wrote:
Basically you have two ways to move around the app (not to use the word
‘navigate’):
- buttons, which will only change the Url if you use Navigation.newUrl
after their click Message returns
- anchor links that will change the url, but to which you have add a
click handler
on
Simon (especially),
I'm trying to figure out the exact same thing you were hung up on, can you
(or anyone else that knows) please inform on what changes you made to get
it working? I've tried doing exactly what you demonstrated in your example
and run into the same issues:
Thanks Erik, I think I got it.
In case of not found, I prefer the not found message over not found page.
With your explanations in this thread, I'll probably be able to do that.
If not, I'll be back here :)
--
You received this message because you are subscribed to the Google Groups "Elm
Erik,
thanks so much. I now understand everything. What had confused me was the
example in the Navigation library. Because that uses hash-routing , it can
work with anchors and not need to create Messages and use preventdefault. I
had inferred too much form that about how to work with ordinary
that should say :
Simon, I'm just glancing at this code, but this page *shouldn't* perform
page refreshes at all. It should only fire UrlChange events without reload
the browser. Am I missing something?
On Saturday, November 26, 2016 at 5:59:56 PM UTC-5, Erik Lott wrote:
>
> The aim is to get
>
> The aim is to get the navigation history ticking along properly without
> page refreshes.
Simon, I'm just glancing at this code, but this page should perform page
refreshes at all. It should only fire UrlChange events without reload the
browser. Am I missing something?
On Saturday,
Wouter, in regards to that sequence of events, I would reduce sequence to
the following question: What does my elm app do when the address bar is
"/apples/234" ? If apple 234 exists, show the apple page. If apple 234 does
not exist, show a "Not Found" page.
IMHO if the user types the url
>
> With option 1 how do you stop the page reloading on each click on an
> anchor?
I'm not sure I understand. I would think that you would want a UrlChange
msg to be fired each time one of these anchors were clicked. I think I'm
missing the point, so let me know.
Another Con of option 1
Here is some code to make things more concrete
https://gist.github.com/simonh1000/9368f9dbd7f93646207ec27fdf3662a2
It is based on the example from the Navigation library, but with the links
changed from # to (I think they are called) HTML5 links.
I added an onClick handler to provide a
Thank you for the explanation Erik! With the upgrade to 0.18 and the
changes in navigation, I was wondering which route (pun intended) to follow
with the upgrade. Not sure I follow completely though.
In option 1, could you deal with redirect-like scenario's inside the SPA?
Like
1. user is
With option 1 how do you stop the page reloading on each click on an anchor?
Another Con of option 1 might be that it can't cover so many scenarios.
Suppose that you have a form, click submit and then - on successful
completion of some persistence stage - you want to redirect to another
page.
>
> 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
-
>
> One of the main benefits of routing/navigation is that a user can bookmark
> or send a URL to someone else, and the website loads up in the correct
> state. Option number 1 seems like it would handle this case naturally. I'm
> not sure how it would work for option number 2.
The
One of the main benefits of routing/navigation is that a user can bookmark
or send a URL to someone else, and the website loads up in the correct
state. Option number 1 seems like it would handle this case naturally. I'm
not sure how it would work for option number 2.
--
You received this
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
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
17 matches
Mail list logo
