10 ms·

> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser sessi

> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local state (useState) Then using Controller pattern, within the controller I use 4 types of hooks, 1 navigation (useHistory), 2 read global state (useSelector), 3 dispatch an action (useDispatch), 4 useEffect() to execute on props change or component mount. That's it, that's where the realm of React and UI ends for me, everything else is in Ducks, Ducks are single file or folder per module that contains Actions, Epics (Obervables) or Sagas (generators), Reducers, initial state of store and Typescript types. I really like this separation of concerns: - dumb components: to worry just about the looks and local state. - controllers: to worry about data in, actions out, life cycle and navigation. - Ducks: Management of data fetching and global state. I wrote this from the top of my head, but if anyone is interested I'm thinking about writing a demo repository and document this approach, maybe others have done it already this is not new, but practices that I've been collecting along the way.

deleted 6y ago
[deleted]
protonimitate 6y ago
> a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.
- wbobeirne 6y ago
  100% this, I often find myself getting tripped up when reading people's complaints about the JS / React ecosystem until I remember that TypeScript and the ESLint (and typescript-eslint and eslint-plugin-react) recommended config isn't standard in everyone's projects. It saves you from a ton of these headaches. Not that the answer to a complaint of a complex toolchain is more tools in the chain, but it's a wonderful development experience once you develop a collection of tools you really like.
- j-krieger 6y ago
  You don't even need those. React itself will warn you directly in the browser console
duxup 6y ago
Yeah I've moved to this and it is working so far. Hooks manage the data and etc, UI components are almost exclusively just UI that get some props. The UI components all have an else render if for some reason they're missing something / it avoids a crash (along with other easy to see / figure out protections)
- elyobo 6y ago
  I use an HoC to wrap components in an error boundary around key points to avoid total crashes.
  - duxup 6y ago
    Yeah I really should adopt that.
ljm 6y ago
This sounds really interesting, don't get me wrong, but it also shows just how insanely novel and complicated modern frontend dev is. Let's break down the terminology: - hooks - useEffect - useHistory - useSelector - dispatch - action - useDispatch - ducks - Actions - Epics (Observables) - Sagas (generators) - Reducers Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries. And I've seen more, with some places establishing patterns like Compound/Molecule/Atom and such. There's no consistent, underlying principle with them, though. If you're invested in Sagas then you're stuck with a bizarre threading model implemented with generator functions and it's pretty much all-or-nothing. If you're invested in Redux then there's no breaking out of that either, you're always going to be contending with shared global state.
- michaelpb 6y ago
  Not to mention terms that do come from a general programming paradigm, but have a very narrow practical / framework-specific use within frontend dev that makes it even harder for beginners (e.g. "thunk" might be a general term, but I bet most people googling it are just trying to get some Redux tutorial to work, and will end up going down dozens of rabbit holes trying to understand the general concept) I really hate to think how many collective hours have been wasted on new coders who learn JavaScript as their first language --- especially when starting with React and Redux, as it's often taught --- and end up spending most of their time spinning their wheels on these domain-specific complexities, when they haven't even gotten to "while loops" yet. This may even be harder for beginners than understanding, say, one of the classic CS sorting algorithms. New coders don't realize though that whatever degree this stuff is harder, it's a sign of bad tooling or documentation, not that it's somehow intrinsically a harder problem in math / CS, since if you're new you don't know what to expect
  - ljm 6y ago
    React's hooks (and some JSX style things in general) are quite pernicious there because they essentially break JS: you can't use them inside an `if` or a `for` or a `while`, or even within another function. You're no longer writing Javascript, you're writing a restricted subset to avoid undefined behaviour. That alone is a concern, because any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself.
revskill 6y ago
What ? So you put navigation state, query state for each route in redux ?
- deleted 6y ago
  [deleted]
mistersys 6y ago
Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much you're complicating everything by using sagas and actions creators and reducers and selectors and.. and.. and. You don't even realize how bad the boilerplate is until it's all gone. With svelte and some writable and readable stores, I can build apps in a fraction of the time because every time I want to make a change I don't have to start with an action creator, than integrate that into the reducer, then write a selector, then pull it into my component. Oh I guess I need to write an epic with rxjs to fetch the data. Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. Then, there's readable. Now, readable can be used like a reselect selector, but it's also far more powerful. You can subscribe to changes from a writable, or even other readable stores. You can create a readable that fetches your data. You can create a readable that subscribes to firestore collection or document. You can make a readable that combines data from multiple sources. It's all clear and composable. And I didn't have to write an action creator with an action constant called `LOADING_PRODUCTS`, and one called `LOADED_PRODUCTS`, and then one called `UPDATED_PRODUCTS`, and for good measure we should also create an action "PRODUCTS_REQUEST_FAILED" that we'll emit from the epic.
- brundolf 6y ago
  > Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. This sounds very similar to the experience of using MobX. I evangelize it as an alternative to Redux every chance I get; it's incredible how practical and pleasant it is to work with.
buzzerbetrayed 6y ago
I’m glad you’ve found something that works for you, but the fact that each react dev has their own complicated way to build a web app is exactly what made me leave react.
- duxup 6y ago
  Anything where you're sufficiently free to do a lot ... will have that.
kabes 6y ago
This just proves how insane things have become.

deleted 6y ago

[deleted]

protonimitate 6y ago

> a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.

wbobeirne 6y ago
100% this, I often find myself getting tripped up when reading people's complaints about the JS / React ecosystem until I remember that TypeScript and the ESLint (and typescript-eslint and eslint-plugin-react) recommended config isn't standard in everyone's projects. It saves you from a ton of these headaches. Not that the answer to a complaint of a complex toolchain is more tools in the chain, but it's a wonderful development experience once you develop a collection of tools you really like.
j-krieger 6y ago
You don't even need those. React itself will warn you directly in the browser console

duxup 6y ago

Yeah I've moved to this and it is working so far. Hooks manage the data and etc, UI components are almost exclusively just UI that get some props. The UI components all have an else render if for some reason they're missing something / it avoids a crash (along with other easy to see / figure out protections)

elyobo 6y ago
I use an HoC to wrap components in an error boundary around key points to avoid total crashes.
- duxup 6y ago
  Yeah I really should adopt that.

ljm 6y ago

This sounds really interesting, don't get me wrong, but it also shows just how insanely novel and complicated modern frontend dev is. Let's break down the terminology: - hooks - useEffect - useHistory - useSelector - dispatch - action - useDispatch - ducks - Actions - Epics (Observables) - Sagas (generators) - Reducers Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries. And I've seen more, with some places establishing patterns like Compound/Molecule/Atom and such. There's no consistent, underlying principle with them, though. If you're invested in Sagas then you're stuck with a bizarre threading model implemented with generator functions and it's pretty much all-or-nothing. If you're invested in Redux then there's no breaking out of that either, you're always going to be contending with shared global state.

michaelpb 6y ago
Not to mention terms that do come from a general programming paradigm, but have a very narrow practical / framework-specific use within frontend dev that makes it even harder for beginners (e.g. "thunk" might be a general term, but I bet most people googling it are just trying to get some Redux tutorial to work, and will end up going down dozens of rabbit holes trying to understand the general concept) I really hate to think how many collective hours have been wasted on new coders who learn JavaScript as their first language --- especially when starting with React and Redux, as it's often taught --- and end up spending most of their time spinning their wheels on these domain-specific complexities, when they haven't even gotten to "while loops" yet. This may even be harder for beginners than understanding, say, one of the classic CS sorting algorithms. New coders don't realize though that whatever degree this stuff is harder, it's a sign of bad tooling or documentation, not that it's somehow intrinsically a harder problem in math / CS, since if you're new you don't know what to expect
- ljm 6y ago
  React's hooks (and some JSX style things in general) are quite pernicious there because they essentially break JS: you can't use them inside an `if` or a `for` or a `while`, or even within another function. You're no longer writing Javascript, you're writing a restricted subset to avoid undefined behaviour. That alone is a concern, because any junior programmer getting an introduction through React is going to get a twisted understanding of the language itself.

revskill 6y ago

What ? So you put navigation state, query state for each route in redux ?

deleted 6y ago
[deleted]

mistersys 6y ago

Yeah this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much you're complicating everything by using sagas and actions creators and reducers and selectors and.. and.. and. You don't even realize how bad the boilerplate is until it's all gone. With svelte and some writable and readable stores, I can build apps in a fraction of the time because every time I want to make a change I don't have to start with an action creator, than integrate that into the reducer, then write a selector, then pull it into my component. Oh I guess I need to write an epic with rxjs to fetch the data. Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. Then, there's readable. Now, readable can be used like a reselect selector, but it's also far more powerful. You can subscribe to changes from a writable, or even other readable stores. You can create a readable that fetches your data. You can create a readable that subscribes to firestore collection or document. You can make a readable that combines data from multiple sources. It's all clear and composable. And I didn't have to write an action creator with an action constant called `LOADING_PRODUCTS`, and one called `LOADED_PRODUCTS`, and then one called `UPDATED_PRODUCTS`, and for good measure we should also create an action "PRODUCTS_REQUEST_FAILED" that we'll emit from the epic.

brundolf 6y ago
> Svelte has 2 primitives that replace all of this: readable and writable. You can create a writable store and you call `.update` or `.set` like react setState. Want to separate your update logic from your component logic like in redux? Easy, just export functions to update the store instead of calling `.update` in your components. This sounds very similar to the experience of using MobX. I evangelize it as an alternative to Redux every chance I get; it's incredible how practical and pleasant it is to work with.

buzzerbetrayed 6y ago

I’m glad you’ve found something that works for you, but the fact that each react dev has their own complicated way to build a web app is exactly what made me leave react.

duxup 6y ago
Anything where you're sufficiently free to do a lot ... will have that.

kabes 6y ago

This just proves how insane things have become.