11–20 of 168 posts
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
If you are starting to learn front-end development today, you may question the choice of React. Consider that a decade ago, people who were starting with the frontend were learning jQuery, which is almost irrelevant now.
We have a complex software product, an integrated compliance and risk management system with embedded workflow, automatic highlighting of potential risks due to non-compliance, plans of actions (aka risk management plans), RBAC, ABAC (used to control different things), etc.
The backend does most of the work. What gets presented at the frontend can be complex.
The React component model gives us an almost functional DSL that we use for compact, highly expressive tooling that allows us to integrate common look and feel, table exports, etc., across some really complex data.
We started before Hooks were widely available or widely known, and, we started with class-based components, because we realized pretty quickly we were going to have to do some funky state management, especially where workflow was involved (we want a common look and feel across processes and tasks, so workflow tasks and processes get wrapped in higher level components that call back to other high level components; the forms can have dozens or hundreds of variables, some interdependent, so state has to be communicated up for validation; React handles sending it down).
Our key state management function is a custom signal handler that gets passed as a prop to all sub components, then, via a common wrapper, back up to the high level components that group everything for display and consistency purposes.
As we refined this handler (and a few others), we moved from class-based to functional components.
The functional components are simpler than the class-based components they replaced, with much of the complexity located in one place, the handler.
Our handler allows us to pass state up “just far enough”, and React handles updating all affected components.
Performance is fantastic, validation is easy(ish; it takes some staring to grok how it hangs together), and debugging (once one has grokked, is straightforward(ish; there are edge cases that cause pause, until the “oh, yeah, that” moment).
That functional DSL has allowed us to build several suited-for-purpose DSLs, e.g., our workflow system, which, while not no code, is low code (configuration as code more than anything else).
If we didn’t understand the React state management model, none of this would have been possible.
So I ask, in naïveté, what are people building that they didn’t need to know that?
(We are likely to move to Hooks anytime soon, because we’ve already solved the problem they were introduced for, and without having to rewrite much. Hooks look like we would have to make wholesale changes, in which we see little value, at least right now, OMMV in the future).
Earlier quoted context omitted.
I think that is the point, is that it does not. It is code, and it does what it is told. But it is quite possible to be a professional dev without fully understanding exactly how and why your frameworks doing their thing, so it feels hand-wavy and mysterious.
I'm among the React developers who don't really know how it works under the hood. Recently I needed to code a UI that required mouse drag events. It ran like a pig when I did it in React. I tried a few things to speed it up, but eventually gave up and did the UI in plain old Javascript. It runs a hell of a lot better, but the code does feel a lot more flimsy. Edit: Here's a demo of the UI I built https://www.youtube.…
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
Earlier quoted context omitted.
If you are starting to learn front-end development today, you may question the choice of React. Consider that a decade ago, people who were starting with the frontend were learning jQuery, which is almost irrelevant now.
What would they be using instead?
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
(In fact, I'll go further than this and add that the section on "Escape Hatches" should be re-read by senior/lead engineers, as many have misconceptions due to learning concepts ad-hoc from code of mixed quality: https://beta.reactjs.org/learn/escape-hatches)
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
The idea is you shouldn't really need to. You have tools to memoize expensive operations in a React-friendly way, but even then you shouldn't really have to think about render cycles. YMMV but I the only time I've ever had to really think about this stuff was when trying to frankenstein legacy jQuery code into a React app.
Earlier quoted context omitted.
I think that is the point, is that it does not. It is code, and it does what it is told. But it is quite possible to be a professional dev without fully understanding exactly how and why your frameworks doing their thing, so it feels hand-wavy and mysterious.
I'm among the React developers who don't really know how it works under the hood. Recently I needed to code a UI that required mouse drag events. It ran like a pig when I did it in React. I tried a few things to speed it up, but eventually gave up and did the UI in plain old Javascript. It runs a hell of a lot better, but the code does feel a lot more flimsy. Edit: Here's a demo of the UI I built https://www.youtube.…
JS works in mysterious ways.
If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?
I chose react as I had a large application to make and I knew react had 2 critical libraries I wanted to reuse. Having now learnt react and the underlying ideas, I think Svelte (https://svelte.dev/) may solve the general problem better. However it has less libraries/documentation and community support. If I had more time to learn I would have considered learning it as a potentially superior solution.