Since the introduction of Hooks, I've been struggling with understanding React and React code. For context: UI development is not my full-time job (anymore), and I mostly do backend dev these days. I still read/write React once in a while, but I don't enjoy it anymore.
Here is what I am struggling with: I am not able to grasp the programming model with Hooks. I am not able to read the code easily, nor am I able to easily understand the interactions in the app. "easily" being the keyword here. I can understand what is happening if I put in the effort, but every time, it is a struggle. I switch between languages and platforms all the time, but react code is where I have to take a real pause to understand what is going on.
My suspicion is that this has to do mostly with the names of the Hooks, and how they are used in the code.
* Why are they named useState, useEffect etc? Are there better names if used will make it easier for me to read this code? Are there any other systems/languages (even in JS) where similar constructs are present? What are their names?
* If JSX is anyway getting compiled to JS, why do I have to still deal with strange looking useState and useEffect declarations? Is there a way to get cleaner syntax and make React code read like regular code?
This is mostly a cry for help, and not a criticism of React. I have used React in the past (several years ago, before Hooks) and I used to "get" React.
terminology is one of the many funny things about React, in this release:
> By convention, functions that use async transitions are called “Actions”.
React is the only people who use this "convention". They pick a very meaningless word for their terminology, but then they just can't stick with it and have to name the hook `useTransition` for some reason.
Instead of wasting doc space for sentences like above, why don't they just use the same word for the api and the concept? If you're gonna refer to the concept as "action", then the hook should be useAction. And if you think "action" is a meaningless word and you need to add some explanation about mutation or promises in the docs, then maybe better just call the concept "mutation", "async transition", whatever and same with the hook.
I wrote an article which might help?https://alexkritchevsky.com/2022/10/12/react-2.html
It's based on a theory that hooks click better for a lot of people if they see an MVP implementation of one and understand the programming problem it is solving.
May I suggest a weird approach? Do this if you have the time but I had the same experience as yours regarding the mental model of React and that the ui is a function of your data.
I suggest you to visit Flutters docs and find the section about its architecture, it resembles React a lot!
There a components (Flutters calls it Widget) and each component has its own hooks and states (in Flutter you have setState), it actually helped me grasp the mental model weirdly enough.
AFAIK, the "use" convention is just a convention used to indicate that you're dealing with something that is plugged into React's state management system, and is going to deal with some kind of state change that can cause component re-renders.
It's helpful to remember that functional components are, well, just functions, which on their own don't have any way to preserve their own state without resorting to some kind of global state store. Unlike object instances, which can have members which keep their state across invocations to instance.render(), functional components are just functions which receive props and return something (usually a React.createElement invocation, often disguised with JSX). Since they don't inherently have any way to preserve state, React provides functions to manage state and to trigger re-renders of components. This is what hooks are - they're global functions which manage updating a global state dict behind the scenes, and triggering re-renders when state changes.
* useState declares a stateful variable which is preserved across renders, and a mutator function which is used to update that variable (in the global state dict) and cause React to perform a re-render of any components which depend on that variable.
* useEffect would probably be better named "useSideEffect", since its purpose is to run a callback as a side effect of one of its declared dependencies changing. It is a little overloaded, in that it can run its callback as an effect of: 1. The component initially mounting, 2. the component unmounting, or 3. one of the declared dependencies changing value.
* useMemo is kind of a combination of useState and useEffect, which declares a stateful variable that is preserved across component renders (the memoized value) and uses a generator function to regenerate and save a new version of that variable when a declared dependency changes.
* useCallback can be thought of as a specialized case of useMemo which returns a memoized function.
Essentially all hooks are built on these four (and really, just useState and useEffect, since useMemo and useCallback are trivial derivations from those two).
It's helpful to think about react state as eventual and to treat it as immutable, and to think of components as truly functional constructs, which should just receive external input and return an output. It may be helpful to think of useState values as nothing more than additional values passed to the function by React when it invokes them. When you update state (or run an effect) you aren't changing things in this invocation of the component, you're changing things for the next invocation for the component (and queueing a reinvocation).
Imagine that you have a declared hook `[someState, setSomeState] = useState();`
Calling `setSomeState(val)` doesn't change the value of `someState`, which you should treat as an immutable variable. Instead, it updates the value of `globalStateDict[currentComponentIdentifier]["someState"] = val` and tells React to queue a re-render of this component. React dutifully re-invokes the function, and the second time it's run, the local `someState` variable receives its value from the React-managed global state, which is now `val`.
useEffect is best thought of as a synchronization mechanism between external state and react state and the function it returns may actually be better thought of as a side effect. UseEffect makes sense in this case because you aren’t on the side!
Imagine if react was pure. Just a huge tree of components.
Each one is simply this: (your data) => <your html>
And then at the top you call render({ my data + functions }), your data propagates down the render tree, and you get an html page back. So simple! Just one function that you call. You put your data in the top, you get your html out.
Except.... what if that's too pure, sometimes. Can't a render function just remember a variable between calls? Why can't a render function two thirds down the tree fetch the data if it's needed? When things aren't so pure, you can optionally pull out hooks to break out of the purity. That way you don't have to do everything at the top level and outside of react, if you don't want to. Just bang a useState in at an appropriate level that makes sense, and it'll remember the state between renders.
TLDR - Hooks are a lie. Pretend “hooks” as a term or concept doesn’t exist. Treat every hook as a unique and independent concept and learn each separately and individually.
1. The purpose of specific hooks have silently changed over time - You’re not the only one confused. The React devs themselves were confused about what they wanted to do with hooks. For example, useEffect is for managing side effects according to the old documentation whereas the new documentation says it syncs external systems.
The change in behavior is ok, except the devs are not open about the fact that they’ve changed how they see useEffect. If they did that it would reduce some of the confusion, especially with the naming, since useEffect is named based on the previous purpose rather than the new.
2. Hooks are expensive - The React devs were far too hasty with the creation of hooks. For example, useMemo and useCallback are basically the same thing. There was no reason for both to exist but React devs considered hooks something easy to create and easy to understand so believe in creating many of them.
The problem, however, is that this approach is completely backwards. Creating a new hook should be considered extremely expensive and something to be avoided as much as possible. The reason is that while technically they are indeed often lightweight wrappers that are easy to create and deploy, conceptually they’re extremely heavy. Every hook brings highly impactful behavior which may not be entirely predictable without looking at the source code, and may not be related to other hooks in any ways.
3. Hooks are not a thing - Calling all of them hooks is also a massive mistake because there is very little similarity between their behaviors. The only similarities that exist are the restrictions on them. But there is no similarity in what they can do. So, for example, if you learn what useEffect does, you will have to expend the same amount of mental energy learning what useCallback does as someone who has no idea what useEffect does. As someone who knows about useEffect the only advantage you have learning about useCallback over someone who doesn’t is that you know you can only use it at the top level of a function and maybe a slightly better intuition of hooks breaking the pureness of functions.
4. It’s the Wild West out there - There are only 2 “Rules of hooks”. They must only be used in functional components. They must be used only at the top level of functional components.
The “use” hook doesn’t even follow these. The 2nd “Rule of Hooks” does not apply to it. The use hook does not need to be used only at the top level but can be used within conditionals and loops as well.
Conclusion - The reason you don’t understand hooks is because “Hooks” are a lie. They don’t exist. No one can go in and learn about “hooks” in React and do anything useful with that information. Instead, you have to learn about “useEffect”, and “useState”, and “useCallback” etc and treat them as completely independent and different concepts with no relation to each other to have learnt something useful.
Fundamentally hooks was a linguistic invention designed to hide the fact that when switching from class based components and the well established concept of a component lifecycle, the React devs created around a dozen new independent concepts to replace them. By pretending that all these different independent concepts such as useEffect, useState, etc were not actually independent concepts, but were a single concept called “Hooks”, they were able to sell the transition to developers more easily.
The only doubt in my mind is whether the React devs were even aware of this falsehood that they were spreading. I’m not convinced they themselves understood what they created and were laboring under the same illusions that they were spreading.
There is an underlying context here - hooks are "effects" from OCaml 5+ / Koka / recent Haskell / etc. Sebastian actually was asking in the ECMAScript mailing list several years ago about adding effects to JS. They built hooks hoping they'd get language-native support for extensible-effects.
Remix is probably the most notable, but there’s Astro as well: https://astro.build/
My impression on Remix is fairly solid, but it doesn’t have quite the “just write and deploy” appeal that Vercel’s done quite a good job with, and they’re somewhat trailing behind Next.js in terms of tracking newer React features (which, in practical terms, doesn’t matter much, since even beta Next.js features tend to ship in a very alpha state of quality).
That said, if you’re willing to sweat a bit on getting something deployed, Remix delivers a pretty good experience overall.
I've switched to running new projects on Remix after using Next.js for many years. Remix is just much more sane. Next.js feels like they are aiming to statically precompile everything and do some automagic with the rest all the while locking useful features under Vercel.
I just want to write my SSR applications with dynamic data and deploy them to Docker, Next is making it harder than it needs to be.
> I would much rather be fired from Facebook than Twitter.
Also, it was all over the news that Twitter fired probably based on performance (lines of code, yeah, I know). Wondering if this will make it difficult for the twitter folks to get hired compared to those from FB.
That's not firing on performance, though, it's just nonsense. Some layoffs are _actually_ performance-based, but assuming the thing about the twitter lines of code is true, that's firing based on leadership incompetence, and it would hardly count against people (unless they're applying to IBM in the 1980s, which actually _did_ use line counts for performance management...)
That LOC thing with Twitter is just a big rumor. There are a lot of dumb rumors about Twitter and Musk floating around. Don’t believe / repeat everything you hear.
A dumb sounding thing happened, which wasn’t even a rumor, there were lots of pictures of it - so that means you should believe a lot of other non-credible stuff coming from people who passionately hate Musk?
It is on the listicle of things to make you highly successful.
- Wake up at 4am every day.
- Only hire lucky people (they get to work for you that instantly makes them one of the lucky ones right!?)
- Fire the unlucky people or the people having a bad day (its a pretty bad and/or unlucky day when you get fired, if they had any luck at all you wouldnt have thought of their name when you decided to fire someone)
I don't think they really care who get fired. To those executives in large organizations, individual contributors are no more than a number. As long as they can make the numbers they do care looking better, no one really matters much.
Tastyworks was founded by the founders, CTO, and CFO of Thinkorswim. I worked on thinkorswim institutional desk for several years back in the mid-2000s. Not great brand recognition but a company built for traders by traders.
Very few people use RH as 'investing'. Those will be on boring brokers like Vanguard.
I have a Tastyworks account too - the fills are way better than Robinhood's. As expected, since they charge some amount per trade. But that means that the "free" platform will definitely have more users, just because it's supposedly free (even though you pay for it in the fills, and get frontrunning trades)
>just because it's supposedly free (even though you pay for it in the fills, and get frontrunning trades)
Can you provide a source for this? Citadel (one of the companies robinhood sells order flow to) claims in regulatory filings[1] that the overwhelming majority of orders are executed at market price or better, and that they on average save traders money.
Because they are paying for a supply of (on average) uneducated morons with no edge. Can you imagine how much a professional poker player would pay to be in a tournament with amateurs?
tl;dr: adverse selection. retail traders are less risky to deal with, so market makers can offer better prices to them.
>If the retail trades are random. If retail traders usually buy before the stock goes up, and sell before the stock goes down, the wholesaler would consistently lose money on price risk. (This is called “adverse selection.”) But they don’t. Even now, retail traders tend to be small, dispersed and uninformed. If you sell stock to a retail trader for $58.15, you have no particular reason to think it will go up (or down). The retail traders are trading randomly, which is what allows you to treat this problem as though you were matching them up with each other at a fixed price and collecting a spread. In reality you are matching them up with each other over time, not simultaneously, and the price moves while you are doing it, but the randomness of their trading means that this difference doesn’t matter too much.
>Meanwhile market makers on the public exchange are doing something similar, but with institutional traders who tend to be informed and trade large lots of stock, so their trading does carry a lot more risk of adverse selection. If a big institution buys some stock, that does mean the stock is somewhat more likely to go up, so if you sell them the stock you are somewhat more likely to lose money. This is why the spread on the public exchange—the difference between the $58 best bid to buy the stock and the $58.25 best offer to sell the stock—is so much wider than the 5 cents that the wholesaler charges. The wholesaler is just matching up small pleasant random orders and clipping a spread; the stock-exchange market maker is facing a real risk of being run over by an informed trader.
The numbers are given as examples, not as real figures. If you look at the document from my prior comment the price improvement (and therefore spreads that citadel makes) is on the order of pennies or less.
I don't know the situation now, but both used to sell their order flow to the same place. I used both and fills for pretty much the same. However, I used tasty platform to set up options and then execute them on RH most of the time.
If you are seeing a venue not meeting nbbo you have a whistleblower suit to make which have been quite lucrative.
When I was doing this for work the issues we ran into came down to a) making the orders hit the tape close enough to ensure similar priority b) the size of the orders changing execution depending on venue c) differences in performance per symbol.
This was in a place that was sending a fair amount of orders in. Even then given the above finding statistical relevance was hard.
Well... hactually... This is kind like the opposite of zero-knowledge, where everyone can know your crush just by entering all suspecting names in the link.
Is there a real lock-in in case of 1Password though? I like their UX and integrations, but looks like it is easy to export and move my data to other products if required.
> Sending fraudulent people to jail for a long, long time is fundamental to running a healthy society
Really?! Interesting...
I agree, a functioning society needs good law and order, and some way to prosecute and bring criminals to justice.
But I am personally not convinced that sending someone "to jail for a long, long time" is the solution. How is that productive? I think we need to come up with better ways to serve justice than physically restricting otherwise smart or productive individuals to a room for decades on end. As soon as we are done with abolishing the death penalty, I would want us to start looking at abolishing this "decades long locking up" of folks. I don't have a good solution as I said, but I am convinced that this is not it.
There are many different philosophies of justice. Personally, I find "restorative justice" the most compelling, especially when tempered with the practicality of "preventive justice". But there is also "rehabilitative justice", along with "retributive justice" which is closest to revenge and thus will never lack for popular appeal.
> But I am personally not convinced that sending someone "to jail for a long, long time" is the solution. How is that productive?
At least for murder, one of the strongest predictors of whether a person will kill is if they've killed before. So prison is productive because it makes it more difficult (though not impossible) for a person to keep killing.
Trying to abolishing imperfect parts of society with no tested replacement solution is a dangerous game.
Some people are or became irredeemably antisocial and need to be kept away from society at large. Watch any liveleak video around the mexican cartel if you need a reminder of what evils people are truly capable of.
That being said, sure want to properly reintegrate everyone possible. But society understandably does not exactly welcome past offenders back with welcome arms. It is kind of hard to be productive again when few places will even consider hiring you. That isn't a stigma you can just wish away.
The point of sending them to jail for a long, long time is to protect society from them. Honest people don't deserve to live in a society filled with liars and cheats and conmen. Send them straight to hell
I think the question is whether punitive policies work in that way. I'm fairly comfortable saying this person getting locked up for a long time will probably not deter too many others from doing similar, at a personal level. I suppose it can be argued that it doesn't have to act as a deterrent to individuals at a high rate, but to groups? But... why aren't we then hearing about everyone else that enabled this? (That is, this just encourages more folks to make sure to have a scape goat.)
Or, do we really think it was down to just this one person's actions?
FWIW IMO: This should be marketed to the twitter croud, not the facebook crowd. I have no interest in writing journals for my friends and family, and even if I did, there won't be many who want to read what I write (in my personal network).
But I can see writing for folks with the same interests in tech, business, books or what not. So I am willing to open up my personal journals, but only to complete strangers (anonymously).
IMO while Microsoft and Google should work together to solve this as soon as possible, the longer term solution should not involve Microsoft. This sounds like something Google should fix at their end.
No customization done by the user, including installation of apps should prevent a user from being able to call 911, period.
That's actually a real issue that needs addressing. Any phone that makes 911 calls should still get security updates. All phones that can reach the cell network can still make 911 calls per FCC requirement.
Imagine the worse case scenario where malware infects the phone but requires a credit card to call 911.
Maybe congress will get around to this to make Google and everyone else do the right thing, but from my perspective Google should have done the right thing here.
Worst case scenario? Sounds like best case scenario to me so long as no one is harmed.
It will take some horribly idiotic event like that to get the manufacturers to actually address that when you sell a phone you're selling hardware and software.
If Google are concerned they could fix it more easily that a software update for older, unsupported phones - they could just mark every app that registers itself as a third party dialer as incompatible with older Pixel devices in the Play Store, and remotely remove them from Pixel phones presumably. It'd be a bit "user hostile" but you have to remember that you don't really control the code on your phone if you use Google services, so it's entirely possible for them to act this way.
The thing I think people are missing is that the response from Google indicates that this isn't a Pixel issue. This is a "all android phones on Android 10+" issue.
Without full cooperation from manufacturers, there's really not a lot that can be done outside of blacklisting all dialer apps on the Play store and even that would do little for anything already installed.
I think you miss the point here. Security updates for phones need to be longer than 3 years -- for that reason.
The pixel 2 is already EOL'd 4 years after it's release, but it can still make 911 calls. I believe there are people that still depend upon that phone to make phone calls -- and therefore need 911 when they need it.
Oh definitely. I wasn't disagreeing with that aspect. Everybody had been focusing on how the Pixel line would be able to solve this issue which kinda ignores that bigger issue that the entire industry needs to be maintaining these security updates. There's no good reason for OS security updates to be gated behind manufacturer control.
EOL does mean something. I don't believe 3 years is long enough personally, but even if it was 10 years the same problem would exist, just for older phones. Then it becomes a semantic argument about where phones should ever have an EOL date for critical fixes.
I think Google would argue that malware interfering with your phone after its EOL date is a reason why you should upgrade your phone to a newer model rather than use that as a reason to extend the life of their phone software indefinitely.
What would you like them to do? Google couldn't retroactively make it possible to patch every phone on the planet even if they wanted to, and the phone manufacturers aren't likely to treat this as any more special than the other bugs that they aren't patching
Well, I'd expect them to bring the phones into compliance with the law. Quoting section 22.921:
> Mobile telephones manufactured after February 13, 2000... must incorporate a
special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call...
If a phone can't access 911, it's not legal. Frankly, it's an indictment of the system architects that this bug is possible at all.
But what if I as the user install software on my phone that isn't capable of calling 911?
I own the phone and I am able to install whatever software and whatever operating system I like. I don't want it to seem like I'm defending Google here, but should manufacturers really be responsible for the software someone installs on their portable computer?
Moreso than most, this regulation is written in blood. The reason this and other FCC 911 rules came about was that there were numerous cases of people trying to call 911 and failing due to software "issues". The FCC said enough and mandated that if it were possible to complete a call, the phone is required to.
Installing your own OS that intentionally doesn't support 911 handling would be in the "not possible" category just like a user who cut their antenna. For anything less than that, Google (and other manufacturers) are absolutely responsible for ensuring the 911 code path can't be disrupted. People have literally died from this.
So you are advocating to put anyone who has a rooted phone that doesn't get this dumb update to fix an issue with Microsoft Teams in jail?
Seriously, this sounds like a Teams issues. Google does by default incorporate what is required and it isn't until Teams takes permission from the phone app that an issue even occurs.
I don't think anyone is expecting google to patch every phone on the planet (assuming you mean every android device ever released). But they should be able to patch every phone of theirs including every old pixel and nexus.
And if they can't, they should make it clear to the user/owner that their phone isn't supported and that means that their lives or the lives of others could be in jeopardy as a result. In fact, perhaps their phones should have an expiration date and should just stop working after sometime. Or at least disable critical functionality that their required to be in compliance with (FCC regulations) since they've decided to no longer support the device. Moreover, this date and timeline should be clear from the point in time when you purchase the device.
Of course this could all be done by the network providers only allowing supported devices on their network, but we all know how that would end up.
This isn't just some bug, and if google wants to participate and be taken seriously in this industry, they should stand by their products and customers.
If they can determine that any phone in usage today running Android software may be prone to this bug they should issue an immediate recall on all devices. That's likely to be almost every Android device purchased in the past couple of years. This scale of recall is not without precedent.
I wouldn’t jump to conclusions before we fully understand what’s happening. Maybe this issue was introduced in the latest version of android (that would be my guess seeing that it was just discovered) thus fixing it in a patch release on that version would fix it for everyone. You with an older pixel have nothing to worry about because you couldn’t update to this version anyhow.
It would also be quite cool is 3rd party apps didn't need and use permissions like "listen to who am I calling". Why a chat/online calling application even need that? Only to collect metadata about their users?
There is a reason this materialized with teams and not with any one of the 10's of thousands of other apps out there: Teams is by far the most invasive piece of shit there is, it tries to hook into everything it can get its grubby little endpoints into.
Both parties are to blame. Teams shouldn't have behaved the way it did, Android should have failsafes to prevent this from happening. A great example of not letting developers do what they want...
Sure, Android should absolutely not allow any apps to interfere with 911 calls, and so however Teams achieves this, should not be possible. But some blame certainly goes to Teams here as well for causing the situation by trying.
One thing I do want to point out is that "not allowing any apps to interfere with 911 calls" is much more complex than it sounds:
1. What about someone who has a tablet (with no cellular functionality) but has a VoIP app installed?
Clearly, the only way to call 911 on such a device would be for it to go through the VoIP app, so it seems like Android at the very least still needs VoIP apps to be able to handle 911 calls under certain circumstances, such as when there is no cellular functionality.
2. How about a situation where a cellular phone has no communication with any cell towers (for any network) but has a VoIP app installed and access to wifi?
Unlikely, to be sure, but possible. In this case, the only way for the phone to reach 911 would, again, be through the VoIP app. If 911 access must get through no matter what, Android would have to let the call go through the app, despite that the phone has cellular functionality.
Those are likely just a couple of instances and there's almost certainly others I haven't thought of.
A solution could be to give the Android system dialer first preference. If it fails to call the number (network issues, no signal) it could automatically pass off the call to the first registered VoIP app
That said, the Google Play store should also have more stringent reviews for apps that want dialer access. Their review should verify whether emergency services can be called regardless of signed-in status, and location
I would be happy to get that somewhere in Google someone is either signing off on such a review requirement right now or has done so in the last couple of days.
I suspect that this little tidbit here is the root cause:
"If a Teams client is not located at a tenant-defined dynamic emergency location, emergency calls from that client are screened by a national call center to determine the location of the caller before transferring the call to the PSAP serving that geographic location."
Also, "If a Teams client for a United States Calling Plan user doesn't dynamically acquire an emergency address within the United States, then the registered emergency address is used to help screen and route the call. However, the call will be screened to determine if an updated address is required before connecting the caller to the appropriate PSAP."
Which is a clear violation of Kari's Law. A business phone system in the US is absolutely not allowed to intercept and divert 911 calls.
Maybe you other reasons to drop Teams, but this would not be one.
Google/Android are clearly tasked with handling 911/emergency calls. Teams is not - I doubt that it is even in their spec - they should expect 911 to route right past them.
Google effed up this one big time.
They need to fix it for every app, not just Teams.
It literally does not matter what Teams does - even if Teams maliciously did every wrong thing they possibly can, it's the duty of the phone manufacturer to ensure that 911 still works, it's Google's duty to ensure that Teams or any other app can't break emergency calls no matter how they try; the law literally requires the phone to recognize that a 911 is being made and override any programming (e.g. Teams) that may interfere with that. If Google can't do that with an over-the-air update, they can issue a full recall for all the affected Pixel phones.
My understanding is that emergency calls for any global locale are supposed to be an entirely separate band of communication from regular phone calls — e.g., they must work even without a SIM card, an account, etc.
So, emergency calls should be ENTIRELY OUT OF SCOPE FOR ANY APP software. Period.
It should be a low-level override/bypass, and NO app software software should ever be allowed to even touch emergency calls, let alone required to handle them.
Expecting all apps to handle life-critical emergency calls correctly is a profoundly stupid idea, guaranteed to produce a multiplicity of failures (and if that expectation did exist, Google must damn well announce it as a deadly serious requirement in bold, uppercase, red flashing letters to anyone wanting to use phone_call_handling permissions, but they don't, afaik).
So, we don't need to know anything about Teams or other app software in this case, only about the emergency calls side/back channel, and that any app, including Teams, will ZERO responsibility for handling emergency calls, or even ability to touch them.
So, it is Google that effed up big time here (regardless of Teams' other issues). Unless you make a solid case for the profoundly stupid idea that all phone-related app software should be responsible for handling life-critical emergency calls, your statement is plainly wrong.
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call.
It doesn't matter what Teams does. Android is required to ignore Teams in the case of an emergency call. That's the law.
Here is what I am struggling with: I am not able to grasp the programming model with Hooks. I am not able to read the code easily, nor am I able to easily understand the interactions in the app. "easily" being the keyword here. I can understand what is happening if I put in the effort, but every time, it is a struggle. I switch between languages and platforms all the time, but react code is where I have to take a real pause to understand what is going on.
My suspicion is that this has to do mostly with the names of the Hooks, and how they are used in the code.
* Why are they named useState, useEffect etc? Are there better names if used will make it easier for me to read this code? Are there any other systems/languages (even in JS) where similar constructs are present? What are their names?
* If JSX is anyway getting compiled to JS, why do I have to still deal with strange looking useState and useEffect declarations? Is there a way to get cleaner syntax and make React code read like regular code?
This is mostly a cry for help, and not a criticism of React. I have used React in the past (several years ago, before Hooks) and I used to "get" React.