8 ms·

Clean front end architecture with SvelteKit

105 points by _xivi 4y ago

riogordo2go 4y ago
"I don't recommend having components responsible for querying data because their responsibility is already in presenting the data. More accurately, components need only receive data from view models, format it, and output it to the screen. Instead, I advise you to follow either of the three following ways: Render the data on the server and pass it to components as a view model, as shown in this guide. Use a state management library that supports dispatching actions (e.g. Redux or MobX), deriving view models from the state, and passing them to components as properties." This is opposite to what Next.js new React Server Components stuff is advocating for in the new app/ dir structure. It expects every component to fetch the required data, and just cache any duplicate calls. It's probably good for a Serverless / Edge deployment but I much rather use a MobX store that takes care of state, fetching and mutations.
- kipple 4y ago
  I came from a centralized store background — and honestly I'm falling in love with the decentralized data responsibilities. Between React Query (fetch batching & caching) and Jotai (decentralized state) I love that every component can just take care of itself. No more prop-drilling, everyone just declares their dependencies and takes care of their own.
  - eurasiantiger 4y ago
    That sounds like absolute hell to dig through once you hit N+1 queries.
    - bakugo 4y ago
      Yeah, this is the kind of thing that seems elegant and convenient when the requirements are simple, but completely falls apart as soon as any complexity is involved.
      - sli 4y ago
        This tracks for me as well. Very quickly, you start having to manage 10, 15, 20, or more places where data in a store is being manipulated from outside the store and it quickly becomes unmanageable on anything beyond a toy-sized application. It almost feels like a rite of passage to decentralize like that and then start to pull back when it becomes a nightmare to debug and maintain.
    - MrJohz 4y ago
      That's the purpose of the in-app request caching layer. Another way to see it is that you do have state in a separate store, it's just that you have one piece of state for each resource that can be requested. So it's not that all the components are requesting the /users resource, it's more that all the components a requesting the value of the /users store, and the /users store fetches the data once and determines whether the data is loading, present, needs to be updated, etc.
      - bayesian_horse 4y ago
        That caching layer sounds like a footgun. RTK Query does something similar, offering multiple ways to initiate, update and use the data of the queries.
    - deleted 4y ago
      [deleted]
  - brigadier132 4y ago
    It all sucks. The grass is not greener on the other side. Just wait for the usEffect hell that awaits you.
    - super256 4y ago
      If you end up with useEffect hell, you are coding wrong. As OP said: it deduplicates and caches requests, there is no need to use useEffect. Here is some example code, and imo it‘s really greener than anything else. async function getData() { const res = await fetch('https://api.example.com/...'); if (!res.ok) { throw new Error('Failed to fetch data'); } return res.json(); } export default async function Page() { const data = await getData(); return <main></main>; }
      - tuukkah 4y ago
        Where's the caching in this example?
        panragon 4y ago
        Handled under the hood by Next 13. To be honest, they probably could have done something to make that a bit more obvious when looking at the code - it probably wouldn't hurt to throw in a simple 'cache' keyword or something.
        tuukkah 4y ago
        This is the documentation I could find although it's not for 13 but Beta: https://beta.nextjs.org/docs/data-fetching/caching https://beta.nextjs.org/docs/data-fetching/caching They say there's a new `cache` function in React and they have patched `fetch` to use it by default (for GET requests). Does this include a solution to the N+1 queries issue (container element requests a list of items, then item elements each request their details)? I see you can do pre-fetching, perhaps those can be batched. EDIT: Found an example that uses DataLoader by "caching the cache". The src/api.ts module exports a cached DataLoader for characters, and src/components/CharacterAvatar.tsx imports and calls it during render simply like this: const character = await characters().load(id); https://github.com/AndrewIngram/next-rick-morty https://github.com/AndrewIngram/next-rick-morty
  - gloryjulio 4y ago
    The problem is the moment you need to do complex combination and computation from multiple async sources, it's game over. It's the repeating of the history of flux -> redux back then all over again. Further more, what happens when you need to share this computation across multiple components?
    - kipple 4y ago
      For all of that: Jotai
      - gloryjulio 4y ago
        Yes the point is that in this case the complexity is not by choice. If u have the business needs then u have to deal with them
        kipple 4y ago
        Right, you put the complexity inside the Jotai
  - ikekkdcjkfke 4y ago
    Separation of concerns is nice
- TheFragenTaken 4y ago
  This is probably very tinfoil-haty, but I can't help but wonder how much of this recommendation is a perverse incentive to sell edge compute on Vercel's platform. In general I am very wary of VC-funded open source, like Next.js.
  - epolanski 4y ago
    They poached pretty much the entire react team in order to bet on: - react being the most popular FE library for time to come - gain the user's mindshare as react being now a Vercel product (something which is becoming increasingly true) - users attracted by react and next eventually becoming Vercel customers. They have also tried or employed several other major library authors in order to position themselves uniquely at the crossroads of major FE software and thus be uniquely positioned to transform those users again in Vercel customers. I don't judge any of this negatively or positively but that's the case I see.
    - kevinak 4y ago
      This is just a meme, an overwhelming majority of the React team ar still at Meta.
      - epolanski 4y ago
        A very large chunk of the longest serving and more important jumped ship though.
        KyeRussell 4y ago
        More important? Or more famous?
    - azangru 4y ago
      > They poached pretty much the entire react team I remember they got Sebastian :-) Who else?
      - 4y ago
- bayesian_horse 4y ago
  Something like React Query and other hooks based approaches are fine and very useful for certain scenarios. At the end you always need a hook (or something very similar). But it can lead to defining asynchronous workflows through the nesting of components, controlled by their mounting/unmounting and other state. I much rather have something like RTK Query which lets me both use it in a hook for simplicity and in Thunks or Sagas for more complex things.
- janekm 4y ago
  That sounds to me like it'd cause all sorts of trouble in the real world (authentication, changes to endpoint URLs, difficulty to agglomerate data), and not surprisingly the Next.js documentation states `For now, if you need to fetch data in a Client Component, we recommend using a third-party library such as SWR or React Query.`
locallost 4y ago
Objectively your application has already been designed by the framework you choose. It tells you how to do and where to put most things and it also does all of the heavy lifting, a.k.a. actually doing something useful. The design the application developer needs to be concerned with is how to split functionality into reusable components where it's needed. I mostly see big fails here: a lot of kind of best practice theater, but what you end up with are very complex components doused with concrete. I also see some straw man arguments, e.g. > Developers dislike design because it's time-consuming. I've never met a developer who doesn't like to design. I'd say the vast majority of developers even if tasked with something as simple as creating a button first try to craft a universal solution that can somehow be reused. Instead the correct design methodology most of the time is called KISS. You can always make it more complex later, but making it simpler is usually a lot more difficult.
nathias 4y ago
I view premature abstraction as a type of premature optimization mistake, this is how senior dev bad code is written a lot of the time either because of faulty generalizations and anticipation or a strict adherance to some principle they don't really understand. Because frameworks are sets of premature abstractions it really depends on how they do it and how much of benefit they provide compared to other existing solutions. I think we came a long way and SvelteKit really does provide minmal bloat and redundant complexity.
bayesian_horse 4y ago
There's nothing stopping you to use Redux Toolkit and RTK Query in Svelte. It may not be "clean" from an OOP perspective, but it is trivial to test, mostly without mocking, it is easy to reason with, and even less code and complexity than what this blog tries to push. When developers talk about a "clean way" to do things, I immediately think of overconfidence. Can't help it.
- jmnicolas 4y ago
  When developers talk about a "clean way" I immediately think of an over-engineered and over-abstracted piece of crap that will be so complicated to understand that the next team will rewrite from scratch. YMMV.
  - bayesian_horse 4y ago
    I wanted to be a little more diplomatic.
- acemarke 4y ago
  Yep, we actually have an RTK Query + Svelte sandbox in our examples page! https://redux-toolkit.js.org/rtk-query/usage/examples#svelte https://redux-toolkit.js.org/rtk-query/usage/examples#svelte We've also seen people use RTKQ with Vue and NgRx as well, like this: - https://github.com/SaulMoro/ngrx-rtk-query https://github.com/SaulMoro/ngrx-rtk-query
concerned_ 4y ago
[flagged]
- KyeRussell 4y ago
  [flagged]
archerx 4y ago
> Long gone in the past1 are websites that purely displayed static, seldom changing content to visitors. Today, almost all user interfaces are web applications instead of websites. Most of the websites I visit are static and when they are not their dynamic content is annoying. Look at new vs old reddit for a good example. Most websites would be better off being statically rendered.
- onion2k 4y ago
  These things aren't mutually exclusive. Most websites are static, but most people's time is spent on dynamic websites.
- iLoveOncall 4y ago
  Dynamic in the sense dynamic VS static doesn't mean what you think it means. Being able to collapse a comment thread, or upvote a comment, or post a reply, without reloading the page, means the website is dynamic. Static only means that nothing changes without a page reload, which is thankfully long gone. Also, the new and old reddit are exactly the same in terms of "staticity". It's just that the new design sucks. Similarly I'm sure you'd qualify Facebook of being an evil dynamic website. But open Facebook and HackerNews side by side, the content on the former won't update dynamically more often than the latter.
  - archerx 4y ago
    > Being able to collapse a comment thread, or upvote a comment, or post a reply, without reloading the page, means the website is dynamic. Static only means that nothing changes without a page reload, which is thankfully long gone. No! That is interactive! Dynamic means hot loading content without refreshing the page. I’ve been doing web dev since web 1.0 so again, no.
    - waboremo 4y ago
      Both of you are correct, the list of things is mixed. Interactivity = collapsing a thread Dynamic = posting a reply and it being sent and displayed without reloading the page FWIW, I don't believe Reddit does the latter.
almostdigital 4y ago
SvelteKit's routing pattern is anything but clean. It uses filesystem based routes where every file is called "+page.svelte" (or +page.server.js/ts for API only routes). For anything but a demo app with just a couple of routes it's a headache to navigate. Edit: Another smell of the routing system to me is that you need to resort to complexity like this [1] to have anything but top down inheritance. I love Svelte btw and have used it in many projects. [1] https://kit.svelte.dev/docs/advanced-routing#advanced-layouts-group https://kit.svelte.dev/docs/advanced-routing#advanced-layout...
- 9dev 4y ago
  Having built a rather large app using SvelteKit, I found the routing scheme to make lots of sense actually. You always know what code is located where, concepts transfer everywhere consistently, and concerns are nicely separated.
  - kevinak 4y ago
    This. It might look complicated at first sight, but once you actually use it you really appreciate the way it's structured.
    - pier25 4y ago
      Well yeah you can get used to anything. Doesn't mean it's a good idea to begin with.
  - almostdigital 4y ago
    In theory it seems neat but in practice I'm here with 10 tabs all called "+page.svelte" or "+page.server.ts" and it completely breaks my workflow since I can't tell them apart or navigate with fuzzy name matching. How do you deal with that?
    - kevinak 4y ago
      Generally you should try to get away from clicking around on file tabs and use your command palette but one thing you can do, if you're using VS Code, is change the "Label format" to "short" in the settings.
azangru 4y ago
> Long gone in the past are websites that purely displayed static, seldom changing content to visitors. Today, almost all user interfaces are web applications instead of websites. Erm, how much of the web is still powered by Wordpress, again?
briantakita 4y ago
> Developers dislike contributing to a legacy codebase with high technical debt. It's more than an aesthetic & workflow preferences. It's also a client management risk. Clients who have no development experience are often used to the same level of productivity to create the initial feature set. As development slows due to maintenance & performance issues, the client does not understand why. Clients also will use analogies, such as a mechanic overcharging for work & using words the client does not understand to justify high fees & billable hours...without understanding that changing a complex system with many undocumented & haphazardly implemented parts can create bugs. Enter a maintenance project at your own risk. Due diligence of the business, codebase, and client's temperment, understanding of software development, decision making, & payment schedule can save you from headaches over the next few months.

105 points by _xivi 4y ago

"I don't recommend having components responsible for querying data because their responsibility is already in presenting the data. More accurately, components need only receive data from view models, format it, and output it to the screen. Instead, I advise you to follow either of the three following ways: Render the data on the server and pass it to components as a view model, as shown in this guide. Use a state management library that supports dispatching actions (e.g. Redux or MobX), deriving view models from the state, and passing them to components as properties." This is opposite to what Next.js new React Server Components stuff is advocating for in the new app/ dir structure. It expects every component to fetch the required data, and just cache any duplicate calls. It's probably good for a Serverless / Edge deployment but I much rather use a MobX store that takes care of state, fetching and mutations.

kipple 4y ago
I came from a centralized store background — and honestly I'm falling in love with the decentralized data responsibilities. Between React Query (fetch batching & caching) and Jotai (decentralized state) I love that every component can just take care of itself. No more prop-drilling, everyone just declares their dependencies and takes care of their own.
- eurasiantiger 4y ago
  That sounds like absolute hell to dig through once you hit N+1 queries.
  - bakugo 4y ago
    Yeah, this is the kind of thing that seems elegant and convenient when the requirements are simple, but completely falls apart as soon as any complexity is involved.
    - sli 4y ago
      This tracks for me as well. Very quickly, you start having to manage 10, 15, 20, or more places where data in a store is being manipulated from outside the store and it quickly becomes unmanageable on anything beyond a toy-sized application. It almost feels like a rite of passage to decentralize like that and then start to pull back when it becomes a nightmare to debug and maintain.
  - MrJohz 4y ago
    That's the purpose of the in-app request caching layer. Another way to see it is that you do have state in a separate store, it's just that you have one piece of state for each resource that can be requested. So it's not that all the components are requesting the /users resource, it's more that all the components a requesting the value of the /users store, and the /users store fetches the data once and determines whether the data is loading, present, needs to be updated, etc.
    - bayesian_horse 4y ago
      That caching layer sounds like a footgun. RTK Query does something similar, offering multiple ways to initiate, update and use the data of the queries.
  - deleted 4y ago
    [deleted]
- brigadier132 4y ago
  It all sucks. The grass is not greener on the other side. Just wait for the usEffect hell that awaits you.
  - super256 4y ago
    If you end up with useEffect hell, you are coding wrong. As OP said: it deduplicates and caches requests, there is no need to use useEffect. Here is some example code, and imo it‘s really greener than anything else. async function getData() { const res = await fetch('https://api.example.com/...'); if (!res.ok) { throw new Error('Failed to fetch data'); } return res.json(); } export default async function Page() { const data = await getData(); return <main></main>; }
    - tuukkah 4y ago
      Where's the caching in this example?
      - panragon 4y ago
        Handled under the hood by Next 13. To be honest, they probably could have done something to make that a bit more obvious when looking at the code - it probably wouldn't hurt to throw in a simple 'cache' keyword or something.
        tuukkah 4y ago
        This is the documentation I could find although it's not for 13 but Beta: https://beta.nextjs.org/docs/data-fetching/caching https://beta.nextjs.org/docs/data-fetching/caching They say there's a new `cache` function in React and they have patched `fetch` to use it by default (for GET requests). Does this include a solution to the N+1 queries issue (container element requests a list of items, then item elements each request their details)? I see you can do pre-fetching, perhaps those can be batched. EDIT: Found an example that uses DataLoader by "caching the cache". The src/api.ts module exports a cached DataLoader for characters, and src/components/CharacterAvatar.tsx imports and calls it during render simply like this: const character = await characters().load(id); https://github.com/AndrewIngram/next-rick-morty https://github.com/AndrewIngram/next-rick-morty
- gloryjulio 4y ago
  The problem is the moment you need to do complex combination and computation from multiple async sources, it's game over. It's the repeating of the history of flux -> redux back then all over again. Further more, what happens when you need to share this computation across multiple components?
  - kipple 4y ago
    For all of that: Jotai
    - gloryjulio 4y ago
      Yes the point is that in this case the complexity is not by choice. If u have the business needs then u have to deal with them
      - kipple 4y ago
        Right, you put the complexity inside the Jotai
- ikekkdcjkfke 4y ago
  Separation of concerns is nice
TheFragenTaken 4y ago
This is probably very tinfoil-haty, but I can't help but wonder how much of this recommendation is a perverse incentive to sell edge compute on Vercel's platform. In general I am very wary of VC-funded open source, like Next.js.
- epolanski 4y ago
  They poached pretty much the entire react team in order to bet on: - react being the most popular FE library for time to come - gain the user's mindshare as react being now a Vercel product (something which is becoming increasingly true) - users attracted by react and next eventually becoming Vercel customers. They have also tried or employed several other major library authors in order to position themselves uniquely at the crossroads of major FE software and thus be uniquely positioned to transform those users again in Vercel customers. I don't judge any of this negatively or positively but that's the case I see.
  - kevinak 4y ago
    This is just a meme, an overwhelming majority of the React team ar still at Meta.
    - epolanski 4y ago
      A very large chunk of the longest serving and more important jumped ship though.
      - KyeRussell 4y ago
        More important? Or more famous?
  - azangru 4y ago
    > They poached pretty much the entire react team I remember they got Sebastian :-) Who else?
    - 4y ago
bayesian_horse 4y ago
Something like React Query and other hooks based approaches are fine and very useful for certain scenarios. At the end you always need a hook (or something very similar). But it can lead to defining asynchronous workflows through the nesting of components, controlled by their mounting/unmounting and other state. I much rather have something like RTK Query which lets me both use it in a hook for simplicity and in Thunks or Sagas for more complex things.
janekm 4y ago
That sounds to me like it'd cause all sorts of trouble in the real world (authentication, changes to endpoint URLs, difficulty to agglomerate data), and not surprisingly the Next.js documentation states `For now, if you need to fetch data in a Client Component, we recommend using a third-party library such as SWR or React Query.`

locallost 4y ago

Objectively your application has already been designed by the framework you choose. It tells you how to do and where to put most things and it also does all of the heavy lifting, a.k.a. actually doing something useful. The design the application developer needs to be concerned with is how to split functionality into reusable components where it's needed. I mostly see big fails here: a lot of kind of best practice theater, but what you end up with are very complex components doused with concrete. I also see some straw man arguments, e.g. > Developers dislike design because it's time-consuming. I've never met a developer who doesn't like to design. I'd say the vast majority of developers even if tasked with something as simple as creating a button first try to craft a universal solution that can somehow be reused. Instead the correct design methodology most of the time is called KISS. You can always make it more complex later, but making it simpler is usually a lot more difficult.

nathias 4y ago

I view premature abstraction as a type of premature optimization mistake, this is how senior dev bad code is written a lot of the time either because of faulty generalizations and anticipation or a strict adherance to some principle they don't really understand. Because frameworks are sets of premature abstractions it really depends on how they do it and how much of benefit they provide compared to other existing solutions. I think we came a long way and SvelteKit really does provide minmal bloat and redundant complexity.

bayesian_horse 4y ago

There's nothing stopping you to use Redux Toolkit and RTK Query in Svelte. It may not be "clean" from an OOP perspective, but it is trivial to test, mostly without mocking, it is easy to reason with, and even less code and complexity than what this blog tries to push. When developers talk about a "clean way" to do things, I immediately think of overconfidence. Can't help it.

jmnicolas 4y ago
When developers talk about a "clean way" I immediately think of an over-engineered and over-abstracted piece of crap that will be so complicated to understand that the next team will rewrite from scratch. YMMV.
- bayesian_horse 4y ago
  I wanted to be a little more diplomatic.
acemarke 4y ago
Yep, we actually have an RTK Query + Svelte sandbox in our examples page! https://redux-toolkit.js.org/rtk-query/usage/examples#svelte https://redux-toolkit.js.org/rtk-query/usage/examples#svelte We've also seen people use RTKQ with Vue and NgRx as well, like this: - https://github.com/SaulMoro/ngrx-rtk-query https://github.com/SaulMoro/ngrx-rtk-query

concerned_ 4y ago

[flagged]

KyeRussell 4y ago
[flagged]

archerx 4y ago

> Long gone in the past1 are websites that purely displayed static, seldom changing content to visitors. Today, almost all user interfaces are web applications instead of websites. Most of the websites I visit are static and when they are not their dynamic content is annoying. Look at new vs old reddit for a good example. Most websites would be better off being statically rendered.

onion2k 4y ago
These things aren't mutually exclusive. Most websites are static, but most people's time is spent on dynamic websites.
iLoveOncall 4y ago
Dynamic in the sense dynamic VS static doesn't mean what you think it means. Being able to collapse a comment thread, or upvote a comment, or post a reply, without reloading the page, means the website is dynamic. Static only means that nothing changes without a page reload, which is thankfully long gone. Also, the new and old reddit are exactly the same in terms of "staticity". It's just that the new design sucks. Similarly I'm sure you'd qualify Facebook of being an evil dynamic website. But open Facebook and HackerNews side by side, the content on the former won't update dynamically more often than the latter.
- archerx 4y ago
  > Being able to collapse a comment thread, or upvote a comment, or post a reply, without reloading the page, means the website is dynamic. Static only means that nothing changes without a page reload, which is thankfully long gone. No! That is interactive! Dynamic means hot loading content without refreshing the page. I’ve been doing web dev since web 1.0 so again, no.
  - waboremo 4y ago
    Both of you are correct, the list of things is mixed. Interactivity = collapsing a thread Dynamic = posting a reply and it being sent and displayed without reloading the page FWIW, I don't believe Reddit does the latter.

almostdigital 4y ago

SvelteKit's routing pattern is anything but clean. It uses filesystem based routes where every file is called "+page.svelte" (or +page.server.js/ts for API only routes). For anything but a demo app with just a couple of routes it's a headache to navigate. Edit: Another smell of the routing system to me is that you need to resort to complexity like this [1] to have anything but top down inheritance. I love Svelte btw and have used it in many projects. [1] https://kit.svelte.dev/docs/advanced-routing#advanced-layouts-group https://kit.svelte.dev/docs/advanced-routing#advanced-layout...

9dev 4y ago
Having built a rather large app using SvelteKit, I found the routing scheme to make lots of sense actually. You always know what code is located where, concepts transfer everywhere consistently, and concerns are nicely separated.
- kevinak 4y ago
  This. It might look complicated at first sight, but once you actually use it you really appreciate the way it's structured.
  - pier25 4y ago
    Well yeah you can get used to anything. Doesn't mean it's a good idea to begin with.
- almostdigital 4y ago
  In theory it seems neat but in practice I'm here with 10 tabs all called "+page.svelte" or "+page.server.ts" and it completely breaks my workflow since I can't tell them apart or navigate with fuzzy name matching. How do you deal with that?
  - kevinak 4y ago
    Generally you should try to get away from clicking around on file tabs and use your command palette but one thing you can do, if you're using VS Code, is change the "Label format" to "short" in the settings.

azangru 4y ago

> Long gone in the past are websites that purely displayed static, seldom changing content to visitors. Today, almost all user interfaces are web applications instead of websites. Erm, how much of the web is still powered by Wordpress, again?

briantakita 4y ago

> Developers dislike contributing to a legacy codebase with high technical debt. It's more than an aesthetic & workflow preferences. It's also a client management risk. Clients who have no development experience are often used to the same level of productivity to create the initial feature set. As development slows due to maintenance & performance issues, the client does not understand why. Clients also will use analogies, such as a mechanic overcharging for work & using words the client does not understand to justify high fees & billable hours...without understanding that changing a complex system with many undocumented & haphazardly implemented parts can create bugs. Enter a maintenance project at your own risk. Due diligence of the business, codebase, and client's temperment, understanding of software development, decision making, & payment schedule can save you from headaches over the next few months.