I somehow stumbled across this over the weekend.

There's a React component library (with a deployed storybook):

* https://github.com/trussworks/react-uswds

* https://trussworks.github.io/react-uswds/?path=/story/compon...

> I think my company has been treating it too much like the latter.

I think that's very common.

Swap out some with most. Glad I'm not in an office.

I did something similar. Searching for verify and verification are good for those cases where you signed up with a Gmail email.

You can also navigate to Settings > Security > Signing in with Google to see everywhere that you've used Google Sign in (oAuth).

Sup anon,

I'm from the same area and work in the same niche.

If you have passable React skills and any past experience, you should be employable now.

I wouldn't bother with the todo app. It's too generic on a resume to gauge anything relevant (since more tutorials are copy/paste and don't show any major problem solving).

Just start applying on Seek. There are tons of short term gigs that will take anyone. That's a great place to start.

Portfolios (i.e deployed personal projects) are huge here. This differs a lot from SV where they seem to have less bearing to get you in the door. The main point of note is that the projects need to be unique in some way.

Thanks. I'll finish off the apps but just put in for short contracts as you say. The "years of experience" thing is putting me off though.

The apps I'm building aren't from tutorials. They are solving my problems and those around me.

> And if it gets too much, “sorry I gotta call my boss” is a believable excuse to get out of anything you find awkward or if you’ve had enough. Knowing you have that parachute might make it easier.

Unless this is true, I don't think that's a great idea.

Don't be pathetic and lie. Be honest. What's wrong with saying "Sorry $NEW_PERSON, I have to go. It was great to meet you."

If you're interested in the negative effects of "white lies" I'd recommend picking up Lying by Sam Harris.

I don't agree with the person you're replying to, but this is a bizarre take:

> There is no societal problem for which "just move away" is a solution.

Why make such an absolute?

Here are a collection of societal problems where "just move away" would be a great solution (some are dumb, but I think they're still valid):

* The local community has pushed towards street art in local parks. You strongly dislike street art.

* Your neighbours like to get drunk (in a non-violent way) every night. They're not overly noisy, but they have gross yards and you have a level of concern that the drunks will eventually make a terrible choice that impacts you (such as drunk driving into your bedroom).

* Lack of kids. You have a family of 4 and the local neighbourhood is filled with retired professionals with no kids. You want to live somewhere that enables your kids to socialise.

* Wayne, your long term neighbour, is using meth. He's managing his addiction very well, but he openly shoots up in the shed with his roller door open. You don't like seeing needle drug users shooting rock.

You can't tell the poor to "move away" from their place of residence. They mostly can't Even if their neighbor is a murderer.

The nimby situation is forcing the less fortunate people to commute beyond what is humane. A 2 hour commute is not healthy. And they CAN'T move away, mostly.

I'm curious which societal problems you think are fixed by moving? Indeed moving can resolve the issue for a given individual but I cannot think of any situation in which moving solves the underlying problem.

None of these are what I would call "societal problems".

2 and 4 are problems with individuals, not a society.

That 1 and 3 are, in your words, "dumb", really does affect their validity. These are things you can live with. Unaffordable rent, not as much.

The problem isn't "My rent is too high", the problem is "The rent is too high everywhere I'd want to live". It's affecting a whole population; that's what makes it societal.

Agree 100%. The migration from componentDidMount, componentDidUpdate, etc to useEffect was a major regression in terms of readability.

The return function in useEffect vs. componentWillUnmount is just terrible. This is always a bizarre topic for juniors.

I actually think that useEffect is an amazing abstraction. It lets you group related functionality like subscribing and unsubscribing into one place and makes it very difficult to leak stuff or use stale values.

I didn’t write many class components beforehand though, so my mental model didn’t have to change all that much.

I wrote a lot of class components and getting used to effects was a 2-week-long headache for me. But then it clicked and I can't go back ever again. Hooks are really nice abstraction. However, sometimes I would like people to name their effects: `useEffect(function clickHandler() {})`, but I understand it looks ugly.

I don't disagree that useEffect is a great extraction overall. But the mental load to understand it vs. explicit lifecycle methods is significantly worse.

The ability to subscribe is indeed amazing (this was much more verbose in class components).

Same experience, I've started working with React when Hooks were introduced in a greenfield project. My last experience with JavaScript was jQuery and Angular 1. I was blown away by the functional-declarative approach of React Hooks, I can't believe that people haven't used it before.

agreed. transition from classes to hooks and useEffect was confusing at first but it now seems very predictable and sensible (does get a little hairy when you have one effect dependent on another).

just started writing my own named effects (eg useAuth() for encapsulating firebase auth) and still in a bit of an uncanny valley with doing that - but again it's very logical once you get used to it and actually in the end a simpler mental model of component state.

never want to go back.

junior devs, start with useState, it'll all flow from there.

As someone familiar with the old react API, I agree 100% about useEffect being super arcane.

There's just too much magic going on, which is the same thing that makes me reluctant to write Vue or Svelte (after reading this)

If you use `<script setup>` in Vue, yeah it's some compiler magic similar to Svelte, but otherwise that's not really the case, for example Vue tracks depdendencies using ES6 Proxy, which is just a language feature.

I agree, but it can be made easier by exposing named functions that help like useUnmount

https://github.com/streamich/react-use/blob/master/src/useUn...

Why do you think it's terrible?

Nothing about its usage implies what it actually does. It's about API affordances. You can't simply just read the code as someone inexperienced with React and say "oh, I know what this does". Returning a closure as the result of another closure has no inherent meaning as to when that closure would be called, because there's no "name" for that functionality.

And don't even get me started about the dependencies array, which has different behaviour whether you omit the argument, or pass an empty array, or pass actual `useState` dependencies, or pass other unrelated variables. Again, it's something you just "need to memorize" to use React.

If I hadn't been using React for many years before they introduced useEffect and various other hooks, they would have all been incredibly confusing. They still are really confusing when used in "clever" ways, especially with developers being allergic to writing comments. Even something as simple as `// this will do X when the component unmounts` make reading usages of useEffect 10x easier (vs. having to remember what happens when you return a function)

Sometimes I do miss the simplicity of componentDidMount... I guess you can always still write class-based components. Too bad they're not in vogue anymore! Feels like every library is hooks-based these days.

Totally agree re comments. They're necessary. Hooks do have huge advantages for composability and flexibility, and that can't be denied. But the API is just so arcane.

If my company wasn't a React shop, I'd probably be using Vue. I used Vue at my previous company and liked it a lot.

Headless libraries like `react-table` that use hooks are a revelation though. So nice to get pretty much all the behaviour you could ever need, without it making UI decisions for you. Difficult to use at first and wrap your head around, but hoo boy is it great to have the power to fully control the rendering!

It's very easy to convert a hook to a HoC, purely wrapping that functionality in a class component.

Also true. It just seems like `class` has become a bit of a dirty word, at least the last two places that I've worked on React codebases.

I agree it has. I think this is because hooks have been talked about by facebook as the future of react. There seems to be no appetite for class based react improvements in the future. No wonder people move to the thing that will be better supported, regardless what it is.

Overloading the meaning of native language features is not the most beginner friendly. It’s a quirk you just have to remember.

Compared to an explicit method name it is much less intuitive.

I'm considering something similar (although probably not as large of a lump sum). I want to spend a year~ as a bartender.

I see the /s, but you're right. Those are literally non-scam uses of crypto.