• 3 Posts
  • 52 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle
















  • QuazarOmega@lemmy.worldtoProgrammer Humor@lemmy.mlDiscord != Documentation
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    1 year ago

    That’s a very interesting observation, I have to admit that even I sometimes am too lazy to read documentation from top to bottom and prefer asking a question to someone that already knows. Though I think it can also be attributed to how good a certain text is structured, quality of documentation should account not only for completeness, but also for laying out the information to be easy to parse and highlight the most important parts, which is maybe why I feel “documentation fatigue” in some cases




  • Now I doubt that this is the problem, because those pages shouldn’t become completely blank, but here’s an explanation:

    A single page application is like a native app in the way it behaves, but made with web technologies and manually fit to the browser workflow, in the older, standard approach we just delivered single web pages and maybe added a little interactivity on top with JavaScript so we had routes like these:

    • example.org/index.html
    • example.org/about.html
    • etc.

    Each page is its own html file and you access it with its path.
    Now there is no rule that what goes into the URL bar should match 1 to 1 with the filesystem on the server so you could go on example.org/news.html and actually get served a page that is under 2023/07/28/something-interesting.html, there is logic running on the server that decides that if a client requests the news page, the server should send over today’s news page.
    You’ll see that all the time when you try to go to a page that doesn’t exist anymore and so you are redirected to example.org/404.html saying you asked for some resource, but it wasn’t found.

    In the same vein you can handle these routes on the client , you could send all the content to the user when they enter example.org, but you let JavaScript take care of what to display, so all the text of index, about, etc. is already on your PC and by clicking the links, which will have the same format, maybe minus the .html (though you could absolutely do that before too, just that here it conveys a specific meaning that in fact you aren’t sending requests for html files, but just “routes”):

    • example.org/index
    • example.org/about
    • etc.

    And even if those links appear in your URL bar they have all been resolved on the client with JavaScript, by simply changing the content appearing on the screen and never getting a completely new page, that would have no problem always resolving.

    But when adding state to the mix, where you have something that is really a web app, you can’t always get the same thing back, suppose I have a task list (in reference to technical React example) and create two items, I click on the second and I get example.org/tasks/2, I send you that link and you open the page for the first time on your computer, it won’t work, it will probably fall back to a home route, because your state was different than mine, you had no task 2 yet, this is also called deep-linking. For that to work you have to store that state and since you’re working in the browser you have to rely on its storge APIs, usually there is no storage that is guaranteed to be permanent on a browser, because its settings could affect when/if the storage gets cleared and suddenly I can’t see my task 2 anymore either after some time.