Comment by bern4444 | Hacker News Reader

Comment by bern4444 | Hacker News Reader

Parent Full thread

There's a lot in here that seems off if not quite wrong.

Throwing errors to be caught higher up, the way they manage redirects, and the lack of discussion around managing state (which could on its own solve lots of these problems).

So much of this seems convoluted and unnecessary for a very simple goal of building a dashboard. Their use of Apollo seems to provide no advantage over a basic REST API.

There's frankly very little discussion about actual front end architecture. I'd expect a conversation on a React application architecture to focus on things like how is client side state managed? How is server state managed and kept up to date? Are the two mingled together or kept separate? How are they kept separate? How can you build reusable components? How can you avoid components bloating in size and scope etc

Front End development today - especially with React - is so easy to get running with and there are tons of better articles that actually discuss front end architecture including lots of courses on common patterns. Beyond articles, open source projects themselves often provide great architecture discussions.

Higher order components, react-query for server state, react-router for client side routing, building reusable behaviors with hooks are all good places to get started for actual architectural design

Great feedback.

I’ve been wanting to write more about most everything you mentioned, but ended up writing about a few interesting patterns we implemented recently. I probably should’ve titled the post “A few interesting patterns we implemented recently”.

As for state management solving the problems of pageload validation (instead of our error boundary and redirect mechanisms), can you provide an example?

Totally, I think if this article were titled patterns it'd be more accurate. Architecture has a more specific meaning (at least to me).

As for using state, when you use something like react-router, all those things, path parameters, query parameters etc are stored in state.

You can build hooks that use the hooks provided by react-router to retrieve those values in a useEffect in the relevant components. The hooks you build can be responsible for validating the path/query params, coordinating route changes etc.

The larger idea is to use your state as a means of coordinating messages that any component can hook into. So you could include in each of those detail pages a redirect route component that only fires when the hook you wrote detects that a page is invalid.

To take this to another level. You could build a Higher Order Component that automatically embeds this ability (a redirect component with a custom hook) into your item detail pages so that it's automatic.

I see what you mean.

By way of clarification, I see route validation and pageload validation as potentially separate. For example, a given route parameter may govern a whole scope of pages in the app, so it makes sense to centralize that route validation logic rather than duplicate it in each page’s validation hook. In a more traditional server (like Express), we can just handle requests which contain that route parameter with a particular middleware function that validates the route. However, if we’re just using Next.js’ filesystem router, we have to add validation in the component tree, in a wrapping component. You’re right that we could make a HOC, but then we would either need to apply it to each page file in that directory or just put it in the App render as a wrapping component, which is what we elected to do.

On the other hand, an individual page may need to run some specific logic to validate that particular load. That’s where the page validation hook comes in. We have a centralized permissions spec in the runtime which contains fallback rules for each page, so we can just update the “abort” callback with each route change so that the page can just bail out of the pageload and redirect the client appropriately.

That's the thing. In react, there's no difference between a route and a component (at least with react-router). So you can write logic that applies to a Route and logic that applies to a component the same way and apply it at the appropriate layer.

I don't know how Next.js' filesystem router works, but it seems to perhaps be the cause for this roundabout solution.

You can do middleware in client side routing with react-router similar to how you would with express. That's exactly what hooks are for and you can build your own to enable that functionality at the scope that's needed.

This article is a nice overview of different kinds of state and how to manage them, the code is Angular but the concepts apply to any SPA.

https://blog.nrwl.io/managing-state-in-angular-applications-...

Reply on news.ycombinator.com