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.
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.
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
" 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
You say that nuclear in France is not profitable and so is subsidized (potentially, don't want to argue that here). To back this you use the fact France agreed to a mechanism (ARENH) to sell its electricity BELOW market rates (this is true).
The logical connection makes no sense. If you want to keep something alive and need subsidies for it, why would you on top of that decide to make even more losses on it? Now, we could agree that maybe France did not have the choice to agree. But don't use ARENH as a proof that nuclear is subsidized
When your main stakeholder (French State) forces you to sell your production way below market rates to your competitors, leaving you with a 8bn€ loss for 2022, it's no surprise EDF struggles financially [1].
For context, this measure was an effort to help competitors not rise their prices too much for the end consumers. Instead of taking the money from its budget, the State took it from EDF's.
I can understand it's a stimulating problem for the brain.
In terms of priorities it doesn't make any sense at all to me though. It's hard to get the global population to care and act about what the GLOBAL state of the planet will be by the end of the century.
So I really could not care less if by accident a few people dug a hole in tens of thousand of years at the wrong place and it created an issue. It's not like the whole human population would meet at this same spot and quickly dig a hole deep enough together so that they all get radiated...
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.