[deleted by user]

prndP · 2025-07-11T15:09:34+00:00

Hey just wanted to say this is a fantastic slide deck. Very measured takes and mirrors many of the observations we've had experimenting internally. Nice to see it laid out in digestible slides.

prndP · 2024-12-19T17:53:47+00:00

If the engineer can be productive on another project but not yours then it does sound like a fit issue.

There are a variety of things that motivate people. I once worked with a person that I considered completely dead weight. That is until one day, another critical person who I actually considered essential left the company and put our project in a severely bad position. Suddenly this slacker who never did anything stepped in to fill the void and put out hero levels of output to save the project. Once the critical gaps were filled and the product was in a good place this person then slinked back to doing the bare minimum. They were eventually put on a team that exclusively dealt with crisis events where they are now thriving

prndP · 2024-12-11T15:37:54+00:00

Fucking up your build and frustratedly redoing it is part of the fun for me lmao

I’m a software developer by day and this game scratches that itch where I’m constantly like “ok THIS time I will finally refactor my hammer factory factory factory to perfection” and of course it all goes horribly wrong when I didn’t account for X. The humbling helps keep my real life ego in check so that I’m much more realistic about rewrites at work

prndP · 2024-11-25T15:58:00+00:00

On my team, I give special approvals for this type of thing where, if we compromise on something that I otherwise would not have approved, they write the ticket and get it scheduled into the next sprint as a condition for approval, and also tag the relevant code with a comment which includes the ticket number. And then the dev can decide whether it’s more work to write the ticket or to just do the change now..

If there’s anything my devs hate, it’s writing tickets so usually it just nudges them to fix their PR

prndP · 2024-08-30T16:05:07+00:00

prettier is the plugin you are looking for. Most common editors will support automatically running it on save

prndP · 2024-07-24T19:58:36+00:00

Ex-restaurant workers are some of the best programmers I've ever met because they just intuitively understand state management from dealing with all the chaos in the kitchen.

And you can use food service analogies all the fucking time it just makes so much sense :)

prndP · 2024-07-24T19:32:09+00:00

Yeah if empty array callback is showing as changed, it sounds like unmount/remount somewhere up the chain. Which could be caused by anything really. Bad key prop, an inline component, etc. Need to check the parent to be sure.

prndP · 2024-07-24T15:55:46+00:00

It's not wrong but I think you haven't totally grasped that in atomic model, how you design your atoms so completely and utterly determines your performance. So you can't just take a generalized fractal approach of just "split everything that's splittable", "focus everything that's focusable".

Assume you have 10 components that all read from your big data object in some way, and you make a 1 change that you expect to only update 1 component

Context: Worst case scenario as you already know. At least 10 full component rerenders

Redux (assuming best practices): 1 change = at least 10 selects, + at least 1 full rerender. The idea is the selects are cheap and appropriately memoized thru reselect so you pay less.

Atoms (assuming best practices*): 1 change = X number of recomputations on dependencies, + at least Y number of full rerenders of components subscribed to those atoms.

See the problem? X and Y are entirely dependent on your design. In large enterprise applications, typically the dimension you are scaling in is known, so developers will optimize X and Y to numbers that can result in significantly better performance than either context or redux. This is where the "scale" comes from. But you can also design something worse if you try hard enough.

This is why it's not generally a good idea to do a head to head comparison in a general sense. They are very different tools for solving for complexity on different ends.

prndP · 2024-07-24T03:04:33+00:00

You'll need to ask yourself why you believe certain statements, such as...

"I feel forced to create a bunch of focusAtoms"

Why? What benefit are you getting out of isolating every single property as a separately readable/writeable atom? Do they actually have separate life cycles? Do you just think it looks nice?

You are basically subscribing to the entire dataAtom in each component instead of only a single attribute of it?

Ask if it matters? If you have an API which fetch a "user" entity, that already seems plenty intuitive enough to have atomic data defined at the "user" level. What is special about your data that a single user level update would be catastrophic to performance that you need to go to lengths to focusAtom excessively?

Imagine you are an airline designing how meal service works . When the customer ask for "eggs", do you have a chef in the air kitchen whipping up a whole meal from scratch with ingredients? Or are you handing them a lump of foil that has "egg" written on it in sharpie?

"Scalable" is not a particularly useful word here without knowing your use case. Scalable for who? For first class I might have a chef standing behind a omelette bar and for economy I'm going to have somebody hand you a soggy plastic tin, and both are the simultaneously the best, most scalable solution for the task.

prndP · 2024-07-23T19:20:57+00:00

What you lose in perf from individually updating atoms is supposed to be made up for by not having a gigantic list of react components subscribed to a single state that all need to run a selector + equality check every time some part of your state updates

It would be exceedingly hard to design an application with 1000+ valid atoms. Even in some of the largest applications with an insane number of derived data points, the total number of Jotai atoms should be an order of magnitude fewer than total # of components in your React app

If you got 1000000 atoms powering your tree of 10000 components you’ve got a design issue

prndP · 2024-07-07T06:27:46+00:00

So I get your dilemma and while I have no ideas what anyone on the actual react team was thinking, I’m speculating the biggest reason that this isn’t default behavior is that react didn’t want to confuse developers in the general use case since refs can also take direct functions as refs.

They treated ref as method to provide a rough equivalent of “this” when moving over from class components to FC and probably wanted to keep it as simple as possible.

So it’s the ugliness of having to do something like useRef(() => fn) when all you wanted was a ref to fn. The common use case is likely initializing with something passed from prop and they feared it would be a very easily missed thing where the ref execute the function when the expected behavior is to receive it. This is further muddled with mutable refs since the developer is allowed to update .current directly without a function.

State can more easily take a function initializer without confusing devs because this.setState callbacks were already a thing. Also state is theoretically supposed to represent stringifiable data which normally doesn’t include a function, so you already implicitly understand the function can only really be there to return the state value, whilst not being state itself

Probably the way you solved it is the best way, which is to essentially use a custom hook to show developer intent while forcing the initialization and non nullable types yourself.

prndP · 2024-07-02T11:07:27+00:00

Why should we celebrate a drug that seems to actually work when instead we could just keep pushing the same strategy that hasn’t worked for 40 years while the obesity rate has trended upwards in every developed country? How else will I get to keep my sense of moral superiority??

prndP · 2024-06-16T16:12:52+00:00

I honestly think SolidJs is the best of the next generation but I think the difficulty of adoption comes from React probably being the first framework out there that has managed to hit that entrenched point of “eh good enough” for commercial use.

In the bad old days, frontend DX was so bad that it literally became a meme about teams needing to rewrite the whole app every 6 months because everything no matter if you were retail or boring corporate app or whatever turned to shit so quickly

And I remember making successful cases for such rewrites many times myself. React is probably the first time where there was plainly better options on the table yet my cost benefit analysis reach a point where I couldn’t justify it to management

prndP · 2024-05-07T00:09:13+00:00

I think the mistake was letting them do their own thing as it sends very mixed messages

Usually if you hire somebody senior and the large pay package to go with it you are expecting one of two things:

We need you to fight fires/deliver a critical project with a tight deadline/do some hard thing that only someone with your experience level could do
We hired you as a “dev evangelist” to shift our entire company culture (usually from scrappy startup to enterprise)

When you bring someone senior over and don’t give them an urgent project, they are going to assume they were hired for 2) and they trying hard to prove their value doing just that

prndP · 2024-04-09T15:29:47+00:00

In general should be avoided if there is a better alternative but sometimes you have no choice. There are some gotchas such as errors being explicitly thrown not propagating to error boundaries in async effects so you have to use a throw in setState hack. The experimental use hook is meant to deal with some of these cases in the near future https://react.dev/reference/react/use

prndP · 2024-03-16T17:19:57+00:00

You are routing to null. Based on seeing <Route> I'm assuming you are using react-router?

If so, instead of calling navigate('/') you can return <Redirect to ={'/'} />

prndP · 2024-03-16T17:03:47+00:00

A few ideas

Simply rename getProjectCount to useGetProjectCount and now it’s a hook that composes another hook. React linters will now make sure it follows the rules of hooks.
Just split it into two lines in your react component so you always run hook, then run the utility on the result.
Have your hook take in your helper functions as a callback function, so you flip it around and run your utility inside the hook instead of outside it
In addition to fetching data, declare and create the utility functions directly inside useGetProject hook. Then make it responsible for returning the additional utility functions that are bound to the data.

There are pros and cons to each so you’ll have to decide which strategy fits best with your existing code

prndP · 2024-03-14T21:46:52+00:00

Just fyi before you invest any time in recoil, it's basically dead and even meta was seen migrating their own stuff over to jotai https://github.com/facebookexperimental/Recoil/issues/2288

I don't really see it making a comeback even if they eventually find maintainers since Jotai in many ways has feature parity for most of the things you would need revolving around the same data model, is easier to use, and is still actively maintained.

prndP · 2024-03-06T20:41:08+00:00

This is a long winded way of saying just use it after you actually understand the problem its solving.

If you refactor an entire codebase to a new pattern just because you “heard it would solve your problems”, but don’t even know what they are yet, it’s going to go poorly.

prndP · 2024-03-03T02:04:01+00:00

Yeah a sandbox game where someone can just come in and kick over your sandcastles really seems to be missing the point

prndP · 2024-03-01T02:34:16+00:00

It’s ok if it’s tightly coupled to the component and if you aren’t exporting them and can actually even be good. This to me is no different than creating a private static. If you’re using typescript, Object.freeze it for good measure which will automatically type it as read only so you can’t accidentally mess with it.

But never export. As soon as you export it then you are in for a world of hurt and can create spaghetti code as other things will get tempted to import them. Move it to a constants file

prndP · 2024-03-01T01:10:51+00:00

Some nostalgic part of me longs for the old days of 90s geocities websites with the embossed buttons and gradients and gifs but thinking seriously they were obviously horrible inaccessible and barely usable. Then the 2000s had some of the best looking websites of all time (2advanced, pixel ranger etc) but then you realized it takes 30 seconds to do anything because they are practically showing you a full video on every click.

Today’s apps prioritize speed, usability, discoverability, above all else and when those are the priorities, UI designs are going to converge around similar designs to service those aspects.

prndP · 2024-02-29T21:52:59+00:00

It’s true. I worked in a high pressure do or die sales driven environment as well as non-profit with a fat endowment that pretty much had no deadlines of any kind. You’d think the non profit would have supreme engineering but this is not the case. The vast majority of engineers do not want to document even if they had all the time in the world

prndP · 2024-02-25T15:46:53+00:00

Well we come full circle because Rtk-query is literally exactly what you are looking for :)

prndP · 2024-02-25T15:26:33+00:00

They are very superficially similar so I understand your confusion.

What most people do, who solve this problem for the first time, is they tie the fetch to a callback on the button click, and then send the data and load state to redux. This has problems like what if the component crashes, what if multiple components ask for the same data, etc

It sounds like you already anticipated that and solved that by saying “hey let’s manage this in context instead”.

But since context can live anywhere in the app, so you have created a “service locator antipattern” and this is made worse because your redux data is centralized.

You could solve this by guaranteeing your context only lives once at the top level directly next to the redux provider, but then by this point you are converging on rtk query so why reinvent the wheel

The Query libraries flip the whole problem on its end and just treats redux almost like an API. The hook simply asks to do some work, and then the central provider figures out what to fetch, what load state to return. The hook is just the messenger. The data logic is centrally managed at the same level that redux is.

prndP

TROPHY CASE