search

leptos-rs / book

The home for the Leptos book, which can be found deployed at https://book.leptos.dev
MIT License
59 stars 58 forks source link

routing: add a note regarding path use and dumb http servers #64

Open ydirson opened 4 months ago

ydirson commented 4 months ago

Note this can be seen as something of a first draft:

benwis commented 4 months ago

Note this can be seen as something of a first draft:

* it can be also related to CSR deployment, though the intent is to make the point obvious to readers of the Routing page

* the specific constraints on web hosting should likely be clarified by someone in-the-know, I was not able to find any details

Wouldn't you be able to provide state via query params if you wanted to?

ydirson commented 4 months ago

Wouldn't you be able to provide state via query params if you wanted to?

Sure, and that is surely worth mentioning as an alternative.

Also @diversable mentioned an article that can be used to enrich the CSR hosting options.

benwis commented 4 months ago

Wouldn't you be able to provide state via query params if you wanted to?

Sure, and that is surely worth mentioning as an alternative.

Also @diversable mentioned an article that can be used to enrich the CSR hosting options.

An article on using nginx for angular?

ydirson commented 4 months ago

An article on using nginx for angular?

The interesting part for us is how to configure nginx to serve an app that uses path for routing.

gbj commented 4 months ago

I have not used GitHub Pages or the other services described — are they incompatible with History API-based client-side routing? The typical pattern in single-page apps like this (SPAs) is that you rewrite /* to /index.html, or /my-app/* to /my-app/index.html (and set the router base prop on Router and Routes to my-app).

I have heard occasional requests for hash-based routing related to GitHub Pages, but no one has ever been interested in making a PR to add it when I've asked. I'm very open to it.

If that's the case (that they only support hash-based client-side routing) then it's not so much that you can't use the router to drive state as they you can't use the router.

I don't think adding these paragraphs in this location is the right way to address this. I'm fine with a short note saying that the router isn't compatible with the hash-based routing that these services require, but that we're open to contributions to add it, but this addition is nearly as long as this whole introduction to the router section.