7 ms·

> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your compon

by ng12 4y ago

> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really worrying about when your component renders or re-renders it's probably because there are other issues with your app.

nightski 4y ago
The only case I have is I love to use D3 for vis. But the thing is it's trivial to embed D3 into a react component and either let react handle rendering via svg or honestly just let D3 take over the DOM in that component. I do this all the time and it works very well.
- nawgz 4y ago
  I wrote my own React components using D3 to do the underlying math but setting up my own DOM rendering. It's ok, my thoughts Pros: * I have generic "zoom/pan" implemented. I did this by making a generic ChartContainer with 5 zones - top, right, bottom, left, content - and you specify just the size of the non-content zones (if displaying them at all) and otherwise it behaves responsively (i.e. CSS style on the container is respected in the internal math). When you scroll the left/content/right vertically, or the top/content/bottom horizontally, it virtually scrolls the other components for you. It also of course handles the math, each area of the 5 is passed a DOMRect describing how big of SVG it can render * I have smart edge routing component on a graph; if you are doing the math yourself on how to position the SVG elements, you can easily describe that graph, so smart edge routing is free * my library has themes via CSS vars, and the components written in this way are obviously automatically themed Cons: * it's a bit verbose for sure, takes some small time and focus. After the initial investment in ChartContainer though, they work freaking awesome * D3 graphs often come with sweet animations and such, I don't have any capability to emulate this today, I hate to do performance-heavy things like manually doing math every frame in a hooks-based way, and I don't want MobX in my component library * you sort of lose access to the D3 ecosystem, nothing is free To be honest, I think I have made a top-tier Gantt with the smart edge routing and zoom, my Graph looks sharp too, and for overhead views it's super nice to be able to zoom and pan and show rulers on the side (imagine showing factory layout, or a board layout, etc). Otherwise, if you are doing more traditional pretty eye-catching stuff, it's not quite meant for that approach
  - cyral 4y ago
    I also went this route and used d3 for the math but my own hand-made SVGs for the rendering so that the DOM is all in "react land". You may want to check out this library: https://airbnb.io/visx/ https://airbnb.io/visx/ They converted a ton of d3 features into proper React components
    - nawgz 4y ago
      Nice link, thanks! I built my own axes / legends / mouseovers but this other stuff looks awesome, really nice to be able to compose their parameters too if I offer something like a line chart etc. I will definitely try to integrate some of this
    - davidbarker 4y ago
      I’m a huge fan of visx after discovering it a few years ago. I recently needed to create a custom line chart and looked into numerous React-based libraries but none fit exactly what I wanted, so I went back to visx again. It requires more planning, but the results you can get (just like with d3) are incredible.
    - nazka 4y ago
      Awesome library. I used it back when it was named Vx with react-spring and d3. You can’t beat this combo.
- whimsicalism 4y ago
  Does d3 have a typescript wrapper?
  - eyelidlessness 4y ago
    As in a wrapper with an API more geared towards statically typed usage? Or just type definitions for the existing D3 APIs? The former is really uncommon (or at least not a particularly commonly idiom), but the latter is typically a quick search for @types/${packageName}. If that’s what you’re after, I was curious and saved you a search, because it would be quite surprising to me if something as popular as D3 was missing type defs: https://www.npmjs.com/package/@types/d3 https://www.npmjs.com/package/@types/d3
Tarks 4y ago
The escape hatches were one of the first things I used to explain why I initially liked react, called them exactly that too. "They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"
- quickthrower2 4y ago
  This is why I felt out with Elm. It is harder to escape the hatches with it.
  - aliswe 4y ago
    you dont escape hatches; you escape THROUGH the hatches
    - deleted 4y ago
      [deleted]
    - quickthrower2 4y ago
      So not \h\a\t\c\h\e\s ?
  - mejutoco 4y ago
    You can use the ports system and interoperate with js in Elm. I used it in the past and it is quite a clean abstraction.
    - bigDinosaur 4y ago
      It's frustrating that it forces you to jump into handling async code, though, in all cases. This wasn't always the case, and for good reason: sometimes async code is just vastly more complicated for no actual benefit if you can tolerate the FFI causing a crash at any calling point. The interest in Elm took a major hit after the compiler banned use of JS.
    - quickthrower2 4y ago
Esther432q 4y ago
ricardobeat 4y ago
React doesn’t offer any render optimizations by default, so not worrying about it sounds like blissful ignorance - you’re just ignoring a ton of unnecessary renders because they don’t visibly affect performance (on your development device). After a certain level of complexity the issues will start to show.
- 5Qn8mNbc2FNCiVV 4y ago
  What's there to optimize? If you don't use state, it doesn't rerender. If you click a button to add another element for example, it does exactly that. If you have a reactive variable in your HTML and update it it rerenders that part only. What's there to optimize further?
  - eyelidlessness 4y ago
    Depending on the complexity of your computations and state, what you just described can basically become unusable. For example, an app I work on implements a spec which: - Models state as an arbitrary DAG - With arbitrarily deep dependency chains - Which may trigger dependent nodes based on only subsets of their state - Based on computations of arbitrary XPath expressions, sometimes containing non-native extensions; these can be expensive whether implemented as a hybrid wrapper around native XPath or fully in userland - Which in turn may trigger recomputation of their own dependent nodes A naive implementation of this according to the algorithm you described will cause real world usage to block sometimes for several seconds until the app becomes responsive again. Being able to have greater control over when to commit state and when to render intermediate state are crucial to usability for this app. Being able to defer the entire computation for state without a path to an associated view is even better. Being able to batch state -> render updates based on priority even better still. All of this can be accomplished with React’s APIs, but it certainly wouldn’t be the default behavior. And it’s all from a real world use case where SolidJS—which has a similar DX to React but significantly better performance, and which I’ve been prototyping for gradual adoption—also needs more optimization than its dependency tracking alone can achieve. Even trivial demo apps with well designed pre-hydration state (note: already optimized beyond the default) and otherwise find performance at runtime can suffer significant lag between LCP and TTI by running far too much code for stuff that’s nowhere near needed for immediate interaction. Granted in most cases this tradeoff is reasonably acceptable. In many cases it’s not. Prematurely optimizing it isn’t a great idea, but there’s a wealth of room for optimizing when it’s valuable to do so.
dvt 4y ago
This has got to be gaslighting at the highest level: oh you're doing something wrong because that's not how you're supposed to do it in React. Not since Java's Spring have I encountered such weird zealotry for a relatively mediocre (but widely popular) framework.
- mondaygreens 4y ago
  Too many folks' livelihoods depend on it at this point. The other side of the same coin is the gaslighting that you can't build anything sufficiently complex without react. If you did build it without react, it obviously wasn't sufficiently complex.
- ng12 4y ago
  I'm fairly certain you're trolling but as a good rule of thumb if you find yourself fighting your framework you picked the wrong one.
  - gopher_space 4y ago
    I'd suggest thinking about dismantling your framework if you've been happy with it for a bit. If you've been rewriting or authoring large chunks and disabling features it might be informative to spend a slow day looking at what you've found useful.
- dmitriid 4y ago
  > Not since Java's Spring have I encountered such weird zealotry for a relatively mediocre (but widely popular) framework. You've now described the Web Components crusade which, among other things, engages in actual gaslighting.
deepstack 4y ago
>If you're really worrying about when your component renders or re-renders it's probably because there are other issues with your app. that's why I prefer Solid instead of React. For client side stuff, Solid is sooo much better than React.
DiggyJohnson 4y ago
I take your point, and can appreciate how more familiarly will lead to greater ability to address these sorts of things, but I do feel like your last two paragraphs / “caveats” could represent a massive edge case.

by ng12 4y ago

nightski 4y ago

The only case I have is I love to use D3 for vis. But the thing is it's trivial to embed D3 into a react component and either let react handle rendering via svg or honestly just let D3 take over the DOM in that component. I do this all the time and it works very well.

nawgz 4y ago
I wrote my own React components using D3 to do the underlying math but setting up my own DOM rendering. It's ok, my thoughts Pros: * I have generic "zoom/pan" implemented. I did this by making a generic ChartContainer with 5 zones - top, right, bottom, left, content - and you specify just the size of the non-content zones (if displaying them at all) and otherwise it behaves responsively (i.e. CSS style on the container is respected in the internal math). When you scroll the left/content/right vertically, or the top/content/bottom horizontally, it virtually scrolls the other components for you. It also of course handles the math, each area of the 5 is passed a DOMRect describing how big of SVG it can render * I have smart edge routing component on a graph; if you are doing the math yourself on how to position the SVG elements, you can easily describe that graph, so smart edge routing is free * my library has themes via CSS vars, and the components written in this way are obviously automatically themed Cons: * it's a bit verbose for sure, takes some small time and focus. After the initial investment in ChartContainer though, they work freaking awesome * D3 graphs often come with sweet animations and such, I don't have any capability to emulate this today, I hate to do performance-heavy things like manually doing math every frame in a hooks-based way, and I don't want MobX in my component library * you sort of lose access to the D3 ecosystem, nothing is free To be honest, I think I have made a top-tier Gantt with the smart edge routing and zoom, my Graph looks sharp too, and for overhead views it's super nice to be able to zoom and pan and show rulers on the side (imagine showing factory layout, or a board layout, etc). Otherwise, if you are doing more traditional pretty eye-catching stuff, it's not quite meant for that approach
- cyral 4y ago
  I also went this route and used d3 for the math but my own hand-made SVGs for the rendering so that the DOM is all in "react land". You may want to check out this library: https://airbnb.io/visx/ https://airbnb.io/visx/ They converted a ton of d3 features into proper React components
  - nawgz 4y ago
    Nice link, thanks! I built my own axes / legends / mouseovers but this other stuff looks awesome, really nice to be able to compose their parameters too if I offer something like a line chart etc. I will definitely try to integrate some of this
  - davidbarker 4y ago
    I’m a huge fan of visx after discovering it a few years ago. I recently needed to create a custom line chart and looked into numerous React-based libraries but none fit exactly what I wanted, so I went back to visx again. It requires more planning, but the results you can get (just like with d3) are incredible.
  - nazka 4y ago
    Awesome library. I used it back when it was named Vx with react-spring and d3. You can’t beat this combo.
whimsicalism 4y ago
Does d3 have a typescript wrapper?
- eyelidlessness 4y ago
  As in a wrapper with an API more geared towards statically typed usage? Or just type definitions for the existing D3 APIs? The former is really uncommon (or at least not a particularly commonly idiom), but the latter is typically a quick search for @types/${packageName}. If that’s what you’re after, I was curious and saved you a search, because it would be quite surprising to me if something as popular as D3 was missing type defs: https://www.npmjs.com/package/@types/d3 https://www.npmjs.com/package/@types/d3

Tarks 4y ago

The escape hatches were one of the first things I used to explain why I initially liked react, called them exactly that too. "They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"

quickthrower2 4y ago
This is why I felt out with Elm. It is harder to escape the hatches with it.
- aliswe 4y ago
  you dont escape hatches; you escape THROUGH the hatches
  - deleted 4y ago
    [deleted]
  - quickthrower2 4y ago
    So not \h\a\t\c\h\e\s ?
- mejutoco 4y ago
  You can use the ports system and interoperate with js in Elm. I used it in the past and it is quite a clean abstraction.
  - bigDinosaur 4y ago
    It's frustrating that it forces you to jump into handling async code, though, in all cases. This wasn't always the case, and for good reason: sometimes async code is just vastly more complicated for no actual benefit if you can tolerate the FFI causing a crash at any calling point. The interest in Elm took a major hit after the compiler banned use of JS.
  - quickthrower2 4y ago

Esther432q 4y ago

ricardobeat 4y ago

React doesn’t offer any render optimizations by default, so not worrying about it sounds like blissful ignorance - you’re just ignoring a ton of unnecessary renders because they don’t visibly affect performance (on your development device). After a certain level of complexity the issues will start to show.

5Qn8mNbc2FNCiVV 4y ago
What's there to optimize? If you don't use state, it doesn't rerender. If you click a button to add another element for example, it does exactly that. If you have a reactive variable in your HTML and update it it rerenders that part only. What's there to optimize further?
- eyelidlessness 4y ago
  Depending on the complexity of your computations and state, what you just described can basically become unusable. For example, an app I work on implements a spec which: - Models state as an arbitrary DAG - With arbitrarily deep dependency chains - Which may trigger dependent nodes based on only subsets of their state - Based on computations of arbitrary XPath expressions, sometimes containing non-native extensions; these can be expensive whether implemented as a hybrid wrapper around native XPath or fully in userland - Which in turn may trigger recomputation of their own dependent nodes A naive implementation of this according to the algorithm you described will cause real world usage to block sometimes for several seconds until the app becomes responsive again. Being able to have greater control over when to commit state and when to render intermediate state are crucial to usability for this app. Being able to defer the entire computation for state without a path to an associated view is even better. Being able to batch state -> render updates based on priority even better still. All of this can be accomplished with React’s APIs, but it certainly wouldn’t be the default behavior. And it’s all from a real world use case where SolidJS—which has a similar DX to React but significantly better performance, and which I’ve been prototyping for gradual adoption—also needs more optimization than its dependency tracking alone can achieve. Even trivial demo apps with well designed pre-hydration state (note: already optimized beyond the default) and otherwise find performance at runtime can suffer significant lag between LCP and TTI by running far too much code for stuff that’s nowhere near needed for immediate interaction. Granted in most cases this tradeoff is reasonably acceptable. In many cases it’s not. Prematurely optimizing it isn’t a great idea, but there’s a wealth of room for optimizing when it’s valuable to do so.

dvt 4y ago

This has got to be gaslighting at the highest level: oh you're doing something wrong because that's not how you're supposed to do it in React. Not since Java's Spring have I encountered such weird zealotry for a relatively mediocre (but widely popular) framework.

mondaygreens 4y ago
Too many folks' livelihoods depend on it at this point. The other side of the same coin is the gaslighting that you can't build anything sufficiently complex without react. If you did build it without react, it obviously wasn't sufficiently complex.
ng12 4y ago
I'm fairly certain you're trolling but as a good rule of thumb if you find yourself fighting your framework you picked the wrong one.
- gopher_space 4y ago
  I'd suggest thinking about dismantling your framework if you've been happy with it for a bit. If you've been rewriting or authoring large chunks and disabling features it might be informative to spend a slow day looking at what you've found useful.
dmitriid 4y ago
> Not since Java's Spring have I encountered such weird zealotry for a relatively mediocre (but widely popular) framework. You've now described the Web Components crusade which, among other things, engages in actual gaslighting.

deepstack 4y ago

>If you're really worrying about when your component renders or re-renders it's probably because there are other issues with your app. that's why I prefer Solid instead of React. For client side stuff, Solid is sooo much better than React.

DiggyJohnson 4y ago

I take your point, and can appreciate how more familiarly will lead to greater ability to address these sorts of things, but I do feel like your last two paragraphs / “caveats” could represent a massive edge case.