Mostly other devs seeing instrument.js everywhere in devtools vs. the actual source. The issue is for all envs and in development has been most problematic.
So obscuring console.log or network initiators the way Sentry currently does.
Webpack and bundlers seem to generally have this problem too. Sourcemaps help resolve when present in dev.
Qualify the duplicate name with why you have a duplicate.
Already have Service and need Service? How bout NewService and Service instead. Or ${NEW_TRAIT}Service and Service. (can replace Service with any domain)
You could also just not duplicate and keep a single Service. Like other mentioned this is likely a design problem at any point names clash.
Oh glad you responded. I'm happy to keep going for the sake of alignment and maybe we'll both find something out of this and the community will have more alignment.
> Route is state too. Loading data based on route is very common. There is no reason to avoid useEffect for triggering side effects based on state or props in components. It's the whole reason it exists...
> Or do you only use libraries for loading data, without realizing they rely on useEffect, perhaps?
I've worked with many teams through this specific issue effectively inventing useEffect many times over before hooks. Loading a document or history change are exactly the types of interactions I was referring to in my comment. Absolutely handle this close to your routing/cache and you won't have to plumb stable objects to deep side-effects in your application.
> Your statements make that difficult.
Statements are hard to see if you don't have empathy for why folks are saying what they are saying it. From what I understand the author's points seems to revolve around their observation that react engineer's don't know things they should.
While I certainly think that is true, in my experience I haven't professionally worked with any react engineers that aligned with any of the author's observation for sr/jr engineers.
I'm curious what your take is on the following:
> Some might also know useRef if they at some point tried to implement some DOM manipulation stuff (more often than not copied from SO) that probably should have been solved in CSS or otherwise.
Most sr/jr people not familiar expect react to work like jquery or need an escape hatch to integrate with some non react lib that's expecting a mount point. In rare cases folks use refs for every element, like jquery, and just can't quite grasp react.
> useEffect and useState combo for processing some data without any side effects
I've never seen this recommended and am not even sure what it means. Anything derived from useEffect is a side effect. I've seen this labeled "derived state" and folks often avoid it.
> One common pattern is the useEffect and useState combo for processing some data without any side effects, causing unnecessary render cycles between data change and computed value update.
I've mostly seen useMemo/useRef/useSelectors used for this. I do agree with author that derived state should proxy to the underlying state and not copy it.
> useCallback and useMemo? Not so much.
Everyone seems to know this. Jr and Sr folks use it all the time, even scenarios where they de-optimize
> Another is lying in the dependency arrays (and disabling that annoying lint rule) for various hooks since it was seemingly the only way to stop that useEffect from triggering the rate limiter of that API you were testing (we all do this from time to time, but removing the dependency is not the right solution).
Never seen this. Maybe forget to add something to the array because they relied too much on react's linter doing this for them.
> Forget about "doing too much work", the primary reason useCallback and useMemo are your friends (and sometimes, useRef) is because they make those function, array and object references stable, and stable references work very well in dependency arrays.
I've never experienced anyone using useCallback, useMemo, or useRef to prevent "doing too much work". Each one has been used for their specific use case with maybe useRef filling in for instance properties that don't trigger any effects.
The only other instance of these hooks i've seen is where useCallback and useMemo used is unnecessarily to keep objects stable in scenarios it didn't quite impact anything downstream. Another variation is where useCallback and useMemo are never stable as intended because the keys aren't stable to begin with. This distinction matters where sr engineers, yes sr, will easily accidentally do something that is effectively useCallback(handle, [Date.now()]).
> But why are these so unknown among so many that seemingly should know better? I guess most people don't really read the docs (breaking news).
I'm pretty sure I've read every version of react's docs since launch and I guess i'm making the same mistakes. Also many of my team members who make constant mistakes with memoization are in the docs daily. I don't think everyone is missing the details you think they are.
> Yes, but it will not actually matter in >99% of real world cases. And this argument is exactly what the article mentions, premature optimization.
The author talks about non of the downsides of their approach. They are real.
> Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and wildly).
useEffect in your component should be rare. Effects should not come from watching state/props. Effects should come from interactions.
> I strongly disagree. The consequences of not using it by default, then arriving at a case where it matters, are so much bigger than the minor performance impact using it "everywhere" has.
Explains why your viewpoint currently aligns with the author. I can tell from what you've said so far you use useEffect too much, which causes you to rely on referential equality more.
> But you need to have experienced this in a large and complex application to really feel it, I suppose.
Following this articles advice will likely make your app render slower than not optimizing at all. Caching everything increases your risk of stale data through misconfiguration. Also the benefits of referential stability only apply to a limited set of components in your overall render tree.
Most data structures and components don't need stability. The issue people have with hooks is primarily caused by 99% of folks not quite understanding just how sparingly hooks should be used.
You should only worry about referential equality once you've profiled a performance issue from some high frequency interaction. This is the only time to useCallback, useMemo, or any form of referential caching.
An element walks into a bar. If your component accepts children or any react elements as props, quite normal, all optimizations around referential equality for its inputs will be flung out the window as that component de-optimizes at every optimization prematurely added.
Another big mistake I see folks of all levels make often is expecting more program design upfront vs. say just managing configurations.
- <Example><Test /></Example>
- <Example => {}} />
- <Example test={{}} />
- <Example tests={[]} />
These all have the same render cost, so there is often no reason to extract function handlers/arrays/objects out of the jsx configuration.
I've been tracking my wholefoods purchases for the last year or so. Just ran my first report and was surprised to see prices have been oddly consistent throughout the year
So obscuring console.log or network initiators the way Sentry currently does.
Webpack and bundlers seem to generally have this problem too. Sourcemaps help resolve when present in dev.