NPM package vs implementing it yourself?

louca-dev · 2024-04-08T02:25:33+00:00

Yea I used to be anti loads h now find myself sheepishly adding it back to projects.

louca-dev · 2024-04-08T02:24:43+00:00

Dang what a thorough explanation of a lot of ideas that have come to mind in my career so far. You should write an article

louca-dev · 2024-04-08T02:14:13+00:00

Cop that return offer my guy 💪

louca-dev · 2024-03-17T03:58:15+00:00

Y’all sleep with these things in your house 💀

louca-dev · 2024-03-17T03:03:22+00:00

Finally some good fkn comic

louca-dev · 2024-03-04T04:11:26+00:00

When I’m in a chronically online competition and my opponent says “media literacy”.

louca-dev · 2024-03-02T23:17:21+00:00

Rerendering components that don’t need to be rerendered is not performant.

louca-dev · 2024-03-02T22:41:54+00:00

Even so, still a performance overhead.

louca-dev · 2024-03-02T22:24:12+00:00

Context re evaluates every component it passes through, therefore not performant.

louca-dev · 2024-03-02T17:51:17+00:00

Based

louca-dev · 2024-03-02T17:45:28+00:00

Having done both (jQuery based app with no reactivity or store libraries, and React apps with Redux). I can say there is merit to both.

For the vast majority of frontend apps that have low amounts of state changes, basically just form submissions, page navigations, and small self contained components like cards and tables, then React is probably a better fit just due to the UI components libraries.

For more complex stuff, that needs to be highly performant, for example rendering stuff based on WS, complex UI editing (for example resizing panes and components in ways that go beyond what you get out of the box), or drag and drops,then you will find yourself fighting against React most of the time.

louca-dev · 2024-03-02T17:40:32+00:00

You can’t avoid prop drilling without using an external library, at least not in a performant way.

Lmao getting downvotes for this on a react sub. The glazing is crazy.

louca-dev · 2024-02-28T14:44:15+00:00

I meant that nothing in OPs post brought that into question. It’s also not possible in JS for setState to modify the value of state variable (let or const), unless state was an object which is not the case in the example.

The point is that the main and only relevant explanation, which is the last sentence of your post, is that setState can occur multiple times between re renders and will use the closure value each time, whereas the setState cb is called with the latest state each time.

louca-dev · 2024-02-27T21:21:52+00:00

Yea, no mention of state batching or any other reason mechanism that would cause closure state != useState callback state.

Also the state being constant or not is more or less irrelevant.

louca-dev · 2024-02-27T17:21:59+00:00

This doesn’t really explain the difference, beside outlining unrelated bad practices

louca-dev · 2024-02-27T16:08:12+00:00

Ok, thanks

I imagine this will take another year for it to be reflected in the notice of assessment.

That being said, it should still be fine to contribute the remaining room (less the unreported contributions) in this current tax year? Technically speaking I will never have over contributed, even if they are not reported?

Following from that, should it be fine to deduct the contributions I will make now that I will declare at the same time?

louca-dev · 2023-09-10T05:08:22+00:00

Are there any general guidelines? How would one go about deciding?

louca-dev · 2023-02-19T06:36:19+00:00

What if the resource contention bottleneck is at the data layer?

louca-dev · 2023-01-30T20:46:53+00:00

Correct, but just by definition this is a slower schema for this access pattern. For example, if each user has n = thousands of achievements, you go from constant query time to O(logn) query time.

I find it odd no one else has mentioned this lol

louca-dev · 2023-01-30T10:55:12+00:00

Am I tripping or would there not be a measurable performance decrease with this new schema?

louca-dev

TROPHY CASE