Like others I disagree that you have to wrap _everything_ in useCallback/useMemo.
However saying you only need those for performance reasons is wrong.
There are cases where avoiding re-rendering (thanks to useCallback) is avoiding an infinite loop.
I created a codesandbox[1] to illustrate this. Wrapping the "reset" function in a useCallback solves the infinite loop.
If your initial reaction is: "you should not create logic like this" or "you're adding unnecessary stuff" please note that this is a stripped down version of a real use case, where things make more sense.
The point is that it's hard to come up with a rule as to when to use useCallback. The best I can think about is: "if you don't have direct vision on where your function will be consumed, wrap it in useCallback". For example, when your function is defined and returned in a hook or defined in a parent component and given to children.
The point is that any of those children/consumers could have this function in a useEffect and so list it as a dependency of this useEffect.
This example doesn't resemble anything someone would actually write though.
There's no reason to reset before setting data again, and I'm not sure why you'd even consider putting the functions in the dependency array for the useEffect in usePets.
I can imagine reasons you'd want to setData in a useEffect (maybe when something else changes, or the user performs some interaction, you fetch new data and then set it), but the dependency would be the thing that indicates that action has happened, and not a reset function returned by a custom hook coupled with your data and setter function.
I tried to address your type of reaction in my "If your initial reaction is(...)" sentence, but that failed.
The point is not that this code is good or bad. It's that it is possible to write such hard to predict code.
Remember this is a stripped down version of some code running in production.
Now to address your specific points anyway:
"There's no reason to reset again": in the non-stripped down version, the hooks rely on a third hook (let's call it "useToken") and needs to react accordingly to this change of token to fetch new data
"I'm not sure why you'd even consider putting the functions in the dependency array for the useEffect in usePets.": unfortunately react-hooks/exhaustive-deps is here to warn you. You can disable or ignore it but I guess you expose yourself to a real missing dependency? Genuinely very keen to hear if you use this rule in your projects and what you do in such cases (where you use a function in the useEffect but do not want to re-run the effect each time this fn changes). To me it's such a weird/unnatural thing to list functions as dependencies because almost all the time functions do not change.
> (The identity of the setCount function is guaranteed to be stable so it’s safe to omit.)
Maybe in JS it still warns in your example because setData is passed in from calling useResource, but at least with Typescript I'm pretty sure eslint infers this
Right now: they don't have such right.
After the law: they do have the right and it requires a judge's approval renewed every 15 days.
I'm not talking about what the capacity of intelligence services to do it, I'm talking about what the police (officier de police judiciaire) can lawfully do.
I'm curious about your opinion on Git. It's actually a tool I'm excited to teach to non-developer people who deal with text documents and the need to keep a history, multiple versions etc. I'm aware that now these features are integrated in some common offices apps so there's less of a need for Git there.
However what's wrong about Git for code? How would you cover the same features differently? When I say "Git" I refer to all the ecosystem that's based on Git, including GUIs for those who don't like the command line
its like using the army to watch over kids crossing the road to school
Many other source control systems with far simpler systems
this whole branch and pr into merge process didn't exist 10 years ago like it does now. It started from open source and low trust - but nobody stopped to ask what problem it solves.
If somebody needs to check your code as part of a formal process - rather than some arbitrary invitation you issue in special cases - you shouldn't of been hired with the job of writing code.
In general it's a hassle when your processor arch, OS version, and node version starts to come into play. NPM doesn't handle this in a great way, especially with native dependencies that need to build, and rely on OS apis. NodeJS isn't particularly stable either.
For example, I used to dev apps on windows, and run them on Ubuntu 16. That worked alright but required minor changes. Moving to Ubuntu 20 on my server required a couple tweaks, and then later moving to deving on Mac required more changes.
Of course keeping old copied of databases is a different story but SQLite is just so convenient compared to backing up full fledged SQL dbs.
These were for old finished projects I wanted to briefly spin up.
" and made it legal to impose a one-off seizure on all accounts above 100k€ overnight" please give a source or at least detail the conditions it can be applied. The way you phrase it sounds like it can be completely arbitrary
Don't we have to use broad terms to avoid abuse of edge cases?
Should we have avoided writing a constitution because "freedom of speech" is extremely vague?
GDPR is a radical step forward considering how poor the situation was. We're talking about a fundamental right to privacy. It was absolutely expected that it would shake some businesses, that's why it was announced years before implementation. Also, the courts don't come suddenly stab companies in the back out of nowhere. There was and there is a lot of pedagogy around it and usually the cases escalates gradually with warnings. The ones getting fines are clearly the ones who are still trying to do it the old way.
There's another way which doesn't involve knowing the relationship with Locke. Basically, in the response shown in the blog post, there's a bit of a contradiction. It says that Hobbes argued for a "strong, centralized government" and further it says "advocated for a separation of powers". When you see a nuance like this, a critical mind would like to explore this nuance deeper:
Q: Did Thomas Hobbes believe in a strong centralized government or in separation of powers?
A: Thomas Hobbes was a philosopher who is best known for his work on political philosophy. He is often associated with the concept of a "social contract," which is the idea that individuals give up some of their natural rights to a central authority in order to better ensure the safety and stability of society as a whole.
Q: Is this central authority meant to be balanced by other powers for Thomas Hobbes?
A: In Hobbes' view, the central authority, or the "Leviathan," as he called it, should have absolute power in order to effectively maintain social order and protect individuals from each other. He did not believe in the concept of separation of powers, or in limiting the power of the central authority in any way. Instead, he thought that the only way to ensure the safety and stability of society was for the central authority to have complete control.
Any modern society is relying on digital supports for most of its administration. Estonia is just proposing more "frontends" to its citizens. Not all of them decide to use it btw (article mentions 46.9% of people use online voting)
So if we're talking about "black swan disaster scenarios" or "catastrophic computer virus", I don't see any difference between Estonia and other countries.
"Their manager might, but engineering managers only want to pay for discrete new capabilities, i.e. making their developers 18% faster when writing code did not resonate strongly enough."
Are there a lot of businesses where individual developer productivity, with a narrow definition of LOC per hour, is the bottleneck?
I've worked for 10 years as a web dev and the bottleneck is very often at the product management level (tickets not ready, goals changing, haven't got the credentials for the 3rd party API yet..) and a minority of the time it's my brain (yes sometimes I need to think before I write code). It's rarely how fast I can write a function. So if you make me 18% faster at something I do 1% of the time... good luck making money out of me
However saying you only need those for performance reasons is wrong.
There are cases where avoiding re-rendering (thanks to useCallback) is avoiding an infinite loop.
I created a codesandbox[1] to illustrate this. Wrapping the "reset" function in a useCallback solves the infinite loop.
If your initial reaction is: "you should not create logic like this" or "you're adding unnecessary stuff" please note that this is a stripped down version of a real use case, where things make more sense.
The point is that it's hard to come up with a rule as to when to use useCallback. The best I can think about is: "if you don't have direct vision on where your function will be consumed, wrap it in useCallback". For example, when your function is defined and returned in a hook or defined in a parent component and given to children.
The point is that any of those children/consumers could have this function in a useEffect and so list it as a dependency of this useEffect.
[1]: Warning, clicking "Start" creates an infinite loop in your browser. https://codesandbox.io/s/intelligent-rgb-6nfrt3