Is your feature request related to a problem? Please describe.
Something is slightly unusual or backwards about the application's URL space at the moment.
All of the application's URLs are defined in terms of hash fragments -- and hash fragments are used by the application's JavaScript code to determine what to display on the page.
To support progressive enhancement, we would render some content into the HTML dynamically on the server-side before the client receives and interprets it.
Both recipe searches and recipe exploration should be good candidates for progressive enhancement.
It's slightly trickier to understand how the starred recipes, meal planner and shopping list could provide progressive enhancement since all state is stored locally on the client.
From a first-pass assessment, it seems like only the contents of index.html should be modified based on the client request. The rest of the application bundle (JS, CSS, and other resources) could remain unchanged.
That implies a strange kind of compatibility dependency: usually the JS, CSS, and other resources depend on the presence of particular elements in the HTML context they are loaded from. In the case of HTML pages rendered with progressive enhancement support, we would want to ensure that those pages contain all of the elements necessary to provide the same dependency guarantees to the JS, CSS, and other resources.
Describe the solution you'd like
Any changes here should be applied carefully, because choosing a URL scheme can have long-term implications (including web archiving, caching, SEO, ...).
We should determine whether progressive enhancement makes sense for the application, and if it does, then to identify subsets of the application where it is relevant, and define URL schemes for those.
Describe alternatives you've considered
Proceeding without any support for progressive enhancement would be possible.
Is your feature request related to a problem? Please describe. Something is slightly unusual or backwards about the application's URL space at the moment.
All of the application's URLs are defined in terms of hash fragments -- and hash fragments are used by the application's JavaScript code to determine what to display on the page.
To support progressive enhancement, we would render some content into the HTML dynamically on the server-side before the client receives and interprets it.
Both recipe searches and recipe exploration should be good candidates for progressive enhancement.
It's slightly trickier to understand how the starred recipes, meal planner and shopping list could provide progressive enhancement since all state is stored locally on the client.
From a first-pass assessment, it seems like only the contents of
index.htmlshould be modified based on the client request. The rest of the application bundle (JS, CSS, and other resources) could remain unchanged.That implies a strange kind of compatibility dependency: usually the JS, CSS, and other resources depend on the presence of particular elements in the HTML context they are loaded from. In the case of HTML pages rendered with progressive enhancement support, we would want to ensure that those pages contain all of the elements necessary to provide the same dependency guarantees to the JS, CSS, and other resources.
Describe the solution you'd like Any changes here should be applied carefully, because choosing a URL scheme can have long-term implications (including web archiving, caching, SEO, ...).
We should determine whether progressive enhancement makes sense for the application, and if it does, then to identify subsets of the application where it is relevant, and define URL schemes for those.
Describe alternatives you've considered Proceeding without any support for progressive enhancement would be possible.
Additional context This could relate somehow to the generation of static content for SEO purposes.