I understand that is what you want, but you cannot reserve yourself from being interpreted when posting on a public forum.
The language you chose to use and the details you chose to focus on is what triggered the response. If your point was that the cartoons was distracting, you could have made that clear in a less disrespectful way (or let the content speak for itself), or perhaps consider if it was worth contributing to the discussion.
Again, you double down on one definition of this particular subculture in another reply. It is reminiscent of how others have tried to define what certain subcultures related to sexual orientation (some now more mainstream) entail, while not being part of them, and I hope you understand how this can be problematic. I appreciate that this may not have been your intention.
sneak wanted OP to be less openly queer in their personal blog for their own comfort, due to their own inability to imagine that the subculture OP is part of is more than their own narrow definition of it.
I guess the disrespect is clearer when one has grown up with its many forms, but assuming your request for more context comes out of a sincere desire to increase your understanding, I hope this helped.
Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.
Because complex applications are now delivered as web apps instead of as desktop applications, and these require complex tooling to maintain. Then everyone wanted to use the same tools in other areas (I guess), where it is probably not necessary in a lot of cases. You see similar trends elsewhere (e.g. cloud, k8s), perhaps CV building is the real reason.
Then again, a lot of the complexity is mostly optional these days. But knowing how to avoid it is tricky, given the amount of tutorials online that will happily convince you to use webpack, redux and whatever else that was made for bigger problems as if they should be used everywhere.
I don't envy young programmers these days, the amount of stuff to wade through is just mindblowing.
I probably wouldn't, since it is very use case specific what concerns are relevant. So more a suggestion to get an overview of the security requirements and privacy requirements one needs to deal with at some point and sketch some possible ways to make those requirements easy to solve when the time comes.
Examples of things to consider: zero trust, multi tenancy, permission structures, user data classification (for GDPR removal/extraction requests).
As a European, GDPR has far reaching consequences that may even dictate what other services you rely on. I.e. can you use that SaaS service for your product when it's located outside of the EU/EEC?
Should maybe add security and privacy to that list, in this day and age. Not that it all needs to be implemented right away (depending on jurisdiction you're operating under) but having a plan for how to solve security and privacy considerations and working with that in mind from the start can make it a much less painful experience in the long run.
I did this on my Android as well, intentionally. My Galaxy S20 defaults to an animation speed that is just so horribly slow, everything feels sluggish. It also uses more battery.
I, too, was a bit confused at the frozen arrow in the beginning, until I realized it was just the loading indicator used when animations are disabled (they could probably improve that one). It is the one place where some sort of movement might still be appropriate.
Anyway, I recently disabled this feature due to it breaking the scroll behaviour in Play Store. Ironically the only app (I've noticed) that uses animation for scrolling in a way that makes this accessibility feature break it, making it a very jarring experience.
Instead, I went into developer tools and scaled all animations down to 0.5x. This at least makes all the annoying transitions bearable. I think this setting should also be exposed under accessibility settings.
My experience with Postgres FTS (did a comparison with Elastic a couple years back), is that filtering works fine and is speedy enough, but ranking crumbles when the resulting set is large.
If you have a large-ish data set with lots of similar data (4M addresses and location names was the test case), Postgres FTS just doesn't perform.
There is no index that helps scoring results. You would have to install an extension like RUM index (https://github.com/postgrespro/rum) to improve this, which may or may not be an option (often not if you use managed databases).
Either way, writing something that indexes your postgres database into elastic/opensearch is a one time investment that usually pays off in the long run.
It doesn't change the fact that tracking your detailed location and who you are around in combination can be used to determine your affiliations or sexual orientation. If you, with your secure iPhone, are located around numerous people with Grindr installed, they may jump to conclusions.
They are capable of targeting gays or political opponents with this, which is the point of the story.
If you want to quickly assess the quality of component libraries like these, especially in terms of accessibility, just take a quick look at their Select/Dropdown implementation.
Their variant breaks all keyboard navigation features and doesn't respond as expected to keyboard only input. If they want to up their game, they should address this before moving out of beta.
> The author talks about non of the downsides of their approach
The whole article is a counterpoint to a common falsehood. The downsides have been overstated a lot already.
> useEffect in your component should be rare.
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 can tell from what you've said so far you use useEffect too much
And I can tell from what you've said that you have fairly limited experience with React, or have not developed a variety of web applications with it.
> The author here is taking their very valid and necessary use case for the optimization of memoization - non-trivial and expensive operations - and extrapolating from that to "just use useMemo
I would say that was your extrapolation, also it never says use useMemo everywhere.
You mention memo, which is different from useMemo in React, so I'm not sure if you are conflating them.
Either way, the main point is using useCallback by default, and using useMemo for non-trivial computed values. This will help you when your app grows in complexity.
If you understand hooks and why react triggers renders, you probably know when useCallback would not be necessary. However, most don't, and tend to err on the wrong side. Then they end up in hook hell when some component 6 levels deep need to use that callback function in a useEffect.
> Following this articles advice will likely make your app render slower than not optimizing at all.
Yes, but it will not actually matter in >99% of real world cases. And this argument is exactly what the article mentions, premature optimization.
> Caching everything increases your risk of stale data through misconfiguration.
Yes, but doing the opposite increases the risk of useEffects triggering unnecessarily (and wildly).
> The issue people have with hooks is primarily caused by 99% of folks not quite understanding just how sparingly hooks should be used.
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.
But you need to have experienced this in a large and complex application to really feel it, I suppose.
The language you chose to use and the details you chose to focus on is what triggered the response. If your point was that the cartoons was distracting, you could have made that clear in a less disrespectful way (or let the content speak for itself), or perhaps consider if it was worth contributing to the discussion.
Again, you double down on one definition of this particular subculture in another reply. It is reminiscent of how others have tried to define what certain subcultures related to sexual orientation (some now more mainstream) entail, while not being part of them, and I hope you understand how this can be problematic. I appreciate that this may not have been your intention.