5 ms·

As a backend engineer I Still haven’t managed to learn how react data management or JSX works. Every time I try to dive into it I get a strong migraine. I hope

As a backend engineer I Still haven’t managed to learn how react data management or JSX works. Every time I try to dive into it I get a strong migraine. I hope something easier comes popular before I would need to learn FE

recursive 3y ago
Have you looked at htmx? Or even full vanilla?
- hankchinaski 3y ago
  htmx better i generally just use vanilla or jquery, htmx it's still bearable
crooked-v 3y ago
JSX is just one-to-one syntactic sugar for a createElement call (https://react.dev/reference/react/createElement https://react.dev/reference/react/createElement). You don't even need to use it with React, any library that defines an identical function interface will do.
- hankchinaski 3y ago
  i just struggle with hooks, data management, how data flows in between components etc etc
  - firecall 3y ago
    You are not alone! I found it useful to actually work through the React tutorials. Keep things simple and learn the simple use cases first. The world of React is now a very busy place, so trying to jump in to a full stack can quickly become overwhelming! FWIW I'm not a fan of how many React and GrpahQL frontends are built. For me it's a lot of complexity for little gain and plenty of pain!
  - ummonk 3y ago
    Data flows top down, from parents to nested children, either explicitly via props or made available as context by parent providers. If data needs to be sent upwards, the parent component must send down a callback which the nested component can call. Hooks are frankly something that you just have to put work into learning though as they can’t be succinctly explained. It’s worth the effort though. Where ordinary programming paradigms result in tangled and messy state, and pure functional paradigms try to pretend state doesn’t exist and stick it all in a monad, hooks provide a framework to handle state in a way that composes much like pure functions do.
  - fendy3002 3y ago
    Hooks making things complicated, before that it's actually simple, let's try to talk with class-based component. There's only two kinds of data inside a component (class-based), first is props. Props is, similar with html attribute, are given to the component by the caller / owner / parent. `<input type="password"/>` has type as the props key, and "password" as it's value. State is data that lives inside a component and cannot in any way accessed by the caller / owner / parent. It can only be accessed by the component itself, or it's children if the component decided to pass it. In general, you'll use very few components with state in a single application unless you know what you're doing with it. So about the data flow, generally data is handled (can be via state or state management libs, see later section) by higher ups (parent) component, and passed to it's children via props. Now the parent component, together with the the value passed, also pass function. The function can be called by the children to update the parents state. As for data management, there's 2 way I usually handle it. First is using state management like mobx and passing it via several ways, usually using react context. State management libraries usually has section on this. Second is to declare the data I needed on top most components (that's relevant to the data itself) via react context, and pass them either via props or make children access them via react context.
    - jonnycoder 3y ago
      I just learned React/Nextjs for a take home coding interview assignment. I used useState a few times. Why would I need redux when there’s useState and useContext? Other than being overly verbose, I think React is ok after building my website with Sveltekit. There just seems to be way more support for off the shelf react components and 99% of jobs ask for React.
      - fendy3002 3y ago
        Don't use redux alone, use redux toolkit or mobx which are more simpler and newer. Sure, you don't need them and can be replaced with useState instead. They shine when you need / can separate the business logic with ui. Think about state management as "backend" for your frontend. What props they have, whether a function will change which props, etc, are belonging to state management. Heck, even the state management can be done in separate project by different team. The best thing, in a bigger org / bigger project, you can have 2 state management code. One is mock, for frontend to develop, which has no dependency with servers, and another is the real one, that really call the backend server for real data.
  - whizzter 3y ago
    I did also, many coming from classic programming that hasn't touched upon functional ways of thinking usually struggle since they're prone to shortcuts whereas React really likes you to keep everything as transformations (or as some would call it functional style). Much React work these days is confined into components, people sadly over-do it also because they perceived Redux as overkill and try to shoehorn entire applications into core React hooks (that are mostly designed for smaller components or at most views). This is needless when Redux (with Redux-toolkit) has recipies that solves the whole-app dataflow problems well (people have issues with Redux because their components got overly complex in the past by shoehorning component issues into Redux instead and now they're complicating things in the other direction). First rule of not messing up React/Redux: Don't mutate data, 90% of messups I see with fresh people is breaking this. Everything should become transforms! To accomplish this the spread operator (...) in JS/TS along with map/reduce/filter are your biggest friends. (You can do optimizations but 98% of the time you won't work on big enough datasets that you need to do that) Thus when you do setX (of state hooks) you set your transformed data, same with sending messages in Redux, your Redux reducer acts upon a message to transform the internal state.
    - recursive 3y ago
      Transforming mutations into react-compatible object creation is not always trivial, particularly with twisty object graphs. I once spent a week trying to untangle a reducer monstrosity that wished it could mutate. In the end, I don't think I totally fixed it. It can be hard.
      - whizzter 3y ago
        Not sure username checks out? :P Joking aside, you're right, often it's almost easier in recursive cases to just go with flat object lists and keeping identities on objects and keep parent id's around. In my view, React is a theoretically beautiful piece of software, and if you're planning on building a synchronized networked system keeping in line with what makes it beautiful will give you it almost for free. For many practical cases (especially smaller SPA's/pages) however it's probably better to just go with Vue or similar and mutate away and let the system handle all update checks for you instead.
- recursive 3y ago
  React `createElement` is not the same as `document.createElement`. The exact behavior of react elements still has a lot of complexity IMO. A react element is not analogous to a DOM element. It's more like a factory for creating a DOM elements. You can put the same react element in a document twice, no problem. That doesn't work for DOM elements. That's just the tip of the iceberg.
  - ojkelly 3y ago
    This is because you define what you want the components result to be. But not how to do it. The return of a component render is a description of more work to do. When that’s done is up to reacts scheduler. Once react has rendered a tree it then commits it to the dom. Manipulating dom elements at runtime is imperative work. Doing it server side you get the same declarative capability as react, but no runtime behaviour. React elements not being 1:1 with the DOM is what enables us to also target native, tuis, and so on.
- koito17 3y ago
  > one-to-one syntactic sugar for a createElement call Used to be, but you are right that JSX is a rather thin syntax over function calls. (The modern JSX transform now uses a _jsx and _jsxs call, depending on whether you are rendering a single child or an array of children). See https://legacy.reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n...
ashconnor 3y ago
I'm not a frontend guy but everything seems more complicated by the fact that Object.observe[0] was ditched. Although there are good arguments against it. [0] - https://caniuse.com/object-observe https://caniuse.com/object-observe [1] - https://www.bitovi.com/blog/long-live-es6-proxies https://www.bitovi.com/blog/long-live-es6-proxies
overstay8930 3y ago
Most frontend engineers don't actually know how it works either, if it makes you feel any better.
willsmith72 3y ago
what about jsx? i find it an amazing mix of html and js and what kind of data management do you mean? for a SPA most people use react query in place of redux these days, otherwise with something like remix you don't need any external data lib
sesm 3y ago
Now imagine how bad pre-react era frameworks were if the main selling point of React was “your SPA is now easier to reason about”.
- recursive 3y ago
  That was a selling point of all the prior (and subsequent) frameworks as well. In fact, that's the selling point of htmx over react too. Opinions vary about how well any of these things achieve that objective.
  - sesm 3y ago
    Before switching to React in 2015 I worked with ExtJS and Backbone, and both of them were much harder to reason about. Oh, and GWT too, that was a nightmare.
    - recursive 3y ago
      I guess different people have different affinity and skills for reasoning about different things. If I knew I'd have to work on react for the rest of my career, I'd find a different line of work, specifically because of how difficult it is for me. Things I've found easier to understand than React include AlpineJS, Solid, Vue, Knockout, and vanilla imperative JS. The only thing I recall ever finding more mind-boggling than React has been Sharepoint-as-an-application-platform.
depressedpanda 3y ago
> As a backend engineer I Still haven’t managed to learn how react data management or JSX works. What are your specific pain points? JSX is HTML-like syntactic sugar, just write normal html but put JS stuff in curly brackets. Data management can be tricky at first, but as long as you remember that everything that isn't memoized (via e.g useState) is recomputed on every render pass, you're 90% there. You can get into the reeds of it of course, but you really don't need to if all you want to do is just build a regular app.

recursive 3y ago

Have you looked at htmx? Or even full vanilla?

hankchinaski 3y ago
htmx better i generally just use vanilla or jquery, htmx it's still bearable

crooked-v 3y ago

JSX is just one-to-one syntactic sugar for a createElement call (https://react.dev/reference/react/createElement https://react.dev/reference/react/createElement). You don't even need to use it with React, any library that defines an identical function interface will do.

hankchinaski 3y ago
i just struggle with hooks, data management, how data flows in between components etc etc
- firecall 3y ago
  You are not alone! I found it useful to actually work through the React tutorials. Keep things simple and learn the simple use cases first. The world of React is now a very busy place, so trying to jump in to a full stack can quickly become overwhelming! FWIW I'm not a fan of how many React and GrpahQL frontends are built. For me it's a lot of complexity for little gain and plenty of pain!
- ummonk 3y ago
  Data flows top down, from parents to nested children, either explicitly via props or made available as context by parent providers. If data needs to be sent upwards, the parent component must send down a callback which the nested component can call. Hooks are frankly something that you just have to put work into learning though as they can’t be succinctly explained. It’s worth the effort though. Where ordinary programming paradigms result in tangled and messy state, and pure functional paradigms try to pretend state doesn’t exist and stick it all in a monad, hooks provide a framework to handle state in a way that composes much like pure functions do.
- fendy3002 3y ago
  Hooks making things complicated, before that it's actually simple, let's try to talk with class-based component. There's only two kinds of data inside a component (class-based), first is props. Props is, similar with html attribute, are given to the component by the caller / owner / parent. `<input type="password"/>` has type as the props key, and "password" as it's value. State is data that lives inside a component and cannot in any way accessed by the caller / owner / parent. It can only be accessed by the component itself, or it's children if the component decided to pass it. In general, you'll use very few components with state in a single application unless you know what you're doing with it. So about the data flow, generally data is handled (can be via state or state management libs, see later section) by higher ups (parent) component, and passed to it's children via props. Now the parent component, together with the the value passed, also pass function. The function can be called by the children to update the parents state. As for data management, there's 2 way I usually handle it. First is using state management like mobx and passing it via several ways, usually using react context. State management libraries usually has section on this. Second is to declare the data I needed on top most components (that's relevant to the data itself) via react context, and pass them either via props or make children access them via react context.
  - jonnycoder 3y ago
    I just learned React/Nextjs for a take home coding interview assignment. I used useState a few times. Why would I need redux when there’s useState and useContext? Other than being overly verbose, I think React is ok after building my website with Sveltekit. There just seems to be way more support for off the shelf react components and 99% of jobs ask for React.
    - fendy3002 3y ago
      Don't use redux alone, use redux toolkit or mobx which are more simpler and newer. Sure, you don't need them and can be replaced with useState instead. They shine when you need / can separate the business logic with ui. Think about state management as "backend" for your frontend. What props they have, whether a function will change which props, etc, are belonging to state management. Heck, even the state management can be done in separate project by different team. The best thing, in a bigger org / bigger project, you can have 2 state management code. One is mock, for frontend to develop, which has no dependency with servers, and another is the real one, that really call the backend server for real data.
- whizzter 3y ago
  I did also, many coming from classic programming that hasn't touched upon functional ways of thinking usually struggle since they're prone to shortcuts whereas React really likes you to keep everything as transformations (or as some would call it functional style). Much React work these days is confined into components, people sadly over-do it also because they perceived Redux as overkill and try to shoehorn entire applications into core React hooks (that are mostly designed for smaller components or at most views). This is needless when Redux (with Redux-toolkit) has recipies that solves the whole-app dataflow problems well (people have issues with Redux because their components got overly complex in the past by shoehorning component issues into Redux instead and now they're complicating things in the other direction). First rule of not messing up React/Redux: Don't mutate data, 90% of messups I see with fresh people is breaking this. Everything should become transforms! To accomplish this the spread operator (...) in JS/TS along with map/reduce/filter are your biggest friends. (You can do optimizations but 98% of the time you won't work on big enough datasets that you need to do that) Thus when you do setX (of state hooks) you set your transformed data, same with sending messages in Redux, your Redux reducer acts upon a message to transform the internal state.
  - recursive 3y ago
    Transforming mutations into react-compatible object creation is not always trivial, particularly with twisty object graphs. I once spent a week trying to untangle a reducer monstrosity that wished it could mutate. In the end, I don't think I totally fixed it. It can be hard.
    - whizzter 3y ago
      Not sure username checks out? :P Joking aside, you're right, often it's almost easier in recursive cases to just go with flat object lists and keeping identities on objects and keep parent id's around. In my view, React is a theoretically beautiful piece of software, and if you're planning on building a synchronized networked system keeping in line with what makes it beautiful will give you it almost for free. For many practical cases (especially smaller SPA's/pages) however it's probably better to just go with Vue or similar and mutate away and let the system handle all update checks for you instead.
recursive 3y ago
React `createElement` is not the same as `document.createElement`. The exact behavior of react elements still has a lot of complexity IMO. A react element is not analogous to a DOM element. It's more like a factory for creating a DOM elements. You can put the same react element in a document twice, no problem. That doesn't work for DOM elements. That's just the tip of the iceberg.
- ojkelly 3y ago
  This is because you define what you want the components result to be. But not how to do it. The return of a component render is a description of more work to do. When that’s done is up to reacts scheduler. Once react has rendered a tree it then commits it to the dom. Manipulating dom elements at runtime is imperative work. Doing it server side you get the same declarative capability as react, but no runtime behaviour. React elements not being 1:1 with the DOM is what enables us to also target native, tuis, and so on.
koito17 3y ago
> one-to-one syntactic sugar for a createElement call Used to be, but you are right that JSX is a rather thin syntax over function calls. (The modern JSX transform now uses a _jsx and _jsxs call, depending on whether you are rendering a single child or an array of children). See https://legacy.reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n...

ashconnor 3y ago

I'm not a frontend guy but everything seems more complicated by the fact that Object.observe[0] was ditched. Although there are good arguments against it. [0] - https://caniuse.com/object-observe https://caniuse.com/object-observe [1] - https://www.bitovi.com/blog/long-live-es6-proxies https://www.bitovi.com/blog/long-live-es6-proxies

overstay8930 3y ago

Most frontend engineers don't actually know how it works either, if it makes you feel any better.

willsmith72 3y ago

what about jsx? i find it an amazing mix of html and js and what kind of data management do you mean? for a SPA most people use react query in place of redux these days, otherwise with something like remix you don't need any external data lib

sesm 3y ago

Now imagine how bad pre-react era frameworks were if the main selling point of React was “your SPA is now easier to reason about”.

recursive 3y ago
That was a selling point of all the prior (and subsequent) frameworks as well. In fact, that's the selling point of htmx over react too. Opinions vary about how well any of these things achieve that objective.
- sesm 3y ago
  Before switching to React in 2015 I worked with ExtJS and Backbone, and both of them were much harder to reason about. Oh, and GWT too, that was a nightmare.
  - recursive 3y ago
    I guess different people have different affinity and skills for reasoning about different things. If I knew I'd have to work on react for the rest of my career, I'd find a different line of work, specifically because of how difficult it is for me. Things I've found easier to understand than React include AlpineJS, Solid, Vue, Knockout, and vanilla imperative JS. The only thing I recall ever finding more mind-boggling than React has been Sharepoint-as-an-application-platform.

depressedpanda 3y ago

> As a backend engineer I Still haven’t managed to learn how react data management or JSX works. What are your specific pain points? JSX is HTML-like syntactic sugar, just write normal html but put JS stuff in curly brackets. Data management can be tricky at first, but as long as you remember that everything that isn't memoized (via e.g useState) is recomputed on every render pass, you're 90% there. You can get into the reeds of it of course, but you really don't need to if all you want to do is just build a regular app.