Trigger routing immediately upon load about seed HOT 14 CLOSED

Related: Attempting to simplify routing syntax further using Regex. (Eg set up a regex map once to match all patterns, and just have the routing events trigger pushState etc.)

from seed.

My understanding is that # routing was a workaround used before pushState was released.

Mozilla's listed advantages of pushState:

"

• The new URL can be any URL in the same origin as the current URL. In contrast, setting window.location keeps you at the same document only if you modify only the hash.

• You don't have to change the URL if you don't want to. In contrast, setting window.location = "#foo"; creates a new history entry only if the current hash isn't #foo.

• You can associate arbitrary data with your new history entry. With the hash-based approach, you need to encode all of the relevant data into a short string.

• If title is subsequently used by browsers, this data can be utilized (independent of, say, the hash).
  "

from seed.

My understanding is that # routing was a workaround used before pushState was released.

but if I'd copy a link like https://example.com/single-page/home and share it with someone else I'd expect that the foreign browser sends a real HTTP request to the server.

from seed.

...e.g. try to open https://seed-rs.org/guide/12 what do you see?

from seed.

I think that's supposed to be handled by the server; I'm not sure how to do it on the hosting I'm using. Ie what's supposed to happen is the server routes all sub-urls to the main one. (And then the framework reads the url and routes appropriately internally)

from seed.

I think that's supposed to be handled by the server;

to be honest, I don't want special frontend logic in my server, I just wanna drop my app on a standard server. But that's only my opinion ;-)

from seed.

Would love to hear what someone more experienced than I with frontend routing thinks

And if anyone knows how to configure Netlify for this to fix the Seed homepage landing-page routing, I'm all ears.

from seed.

Yeah you typically just get the server to serve up index.html on any request, then make the framework trigger and update immediately upon load. For example here is there relevant crates.io code (crates.io is a single-page ember app).

I would recommend against using # for anything other than anchor tags. Routing should be done as 'natively' as possible so back, forward and linking work the same as a static site would.

from seed.

Yeah you typically just get the server to serve up index.html on any request, then make the framework trigger and update immediately upon load.

I see

For example here is there relevant crates.io code (crates.io is a single-page ember app).

yes, here it works as expected :)
As long as I can reproduce the route I'm totally fine with it :)

I would recommend against using # for anything other than anchor tags. Routing should be done as 'natively' as possible so back, forward and linking work the same as a static site would.

Yes, in that way I can agree :)

So this issue is more about making the framework trigger routing and updating immediately upon load.

from seed.

To elaborate a little - since Seed is based on Elm - in production Elm, the main function is Browser.application, which as you can see takes as the init argument a callback that returns ( model, Cmd msg ). This initcallback is called once the app has loaded, and inside that function you would typically set up the model, then parse the URL as typed into the address bar and return some kind of routing message which is then processed as part of the normal event loop.

This seems like a nice way to do it. The framework need not trigger routing itself, but merely provide the URL to some callback.

from seed.

@jesskfullwood I think creating an init argument like that's elegant. In addition to initial routing, it would remove the need to put side-effect (eg loading data from a server) setup code in a did_mount, which feels awkward.

from seed.

Is initial routing not working for y'all as-is? routing::initial gets called on app load, which checks the path against the routes HashMap. API-design-wise, I don't think it's necessary to explicitly specify the initial route, since it should be included in routes.

For me, it works for top-level paths, but fails more than one level down (Or is that my hosting and dev server?) The error I'm getting's difficult to diagnose: SyntaxError: expected expression, got '<', where the web server tries to load the html file as JS.

from seed.

I redid the routing module to use a cleaner, more flexible API (committed; not released on crates), and I'm still not sure if this is a bug in seed, or a problem with server config. In relation to @flosse 's original question, routing now supports location hash and search, although they appear to be bugged atm.

from seed.

Fixed, by @jesskfullwood 's homepage PR reffed above

from seed.