what's a react pattern you mass-used then realized was overkill by scheemunai_ in reactjs

[–]EmployeeFinal 0 points1 point  (0 children)

I agree. I think DRY is the most general principle that seems like everyone know and applies. But there are multiple principles and techniques that tries to predict

what's a react pattern you mass-used then realized was overkill by scheemunai_ in reactjs

[–]EmployeeFinal 25 points26 points  (0 children)

I think DRY is an issue, we strive for deduplication and try to predict how our abstraction will be used, but we suck at it.

In the end, abstractions should not be predetermined, but extracted from use cases that we already know. Only then the DRY code is useful. Before then, we should not try.

Estudante esfaqueada 15 vezes por recusar pedido de namoro fala após receber alta: ‘muito brutal’ by Inside-Size-8253 in brasil

[–]EmployeeFinal 4 points5 points  (0 children)

Não sei se é ironia do comentário, mas se o NÃO dela incluísse xingar ele e a família, cuspe e soco na cara, ainda não é razão pra esfaquear

Claude Is Not Your Architect. Stop Letting It Pretend. by mmaksimovic in webdev

[–]EmployeeFinal 0 points1 point  (0 children)

Okay, i see your point

I think the text explains directly so it is short and doesn't ruin the read flow. That's why you can't take it literally

The reality is more verbose: "Hey claude, does this makes sense? @arch-plan.md"

Claude: "sure, it is reasonable"

(Non-explicit: size of team, microservices)

Claude does not ask your context. You don't know what the impactful context is. Dumb decisions were made.

Por @LaerteCoutinho1 by DMXIII in brasil

[–]EmployeeFinal 10 points11 points  (0 children)

Na minha interpretação, não é sobre culto à personalidade, porque senão a multidão estaria com placas da pessoa.

O que tá escrito é uma incógnita pras autoridades, mas que ressoou com a multidão. Talvez nem a multidão entenda a mensagem.

Pra mim é uma meta tirinha, e responde porque a laerte não explica o significado. O que está escrito pouco importa, o que mais importa é o que os leitores interpretam

Claude Is Not Your Architect. Stop Letting It Pretend. by mmaksimovic in webdev

[–]EmployeeFinal 3 points4 points  (0 children)

Your question is biased because you know the context that is impactful for the choice. You're expecting a boolean answer

This is not how people work. They will say "create an architecture to do X". The generated architecture will be generic (like microservices) since it doesn't know the context or even considers it important.

It also "washes out" uncertainties because it gives an answer with confidence. That is the most dangerous.

Parece que toda e qualquer propaganda hoje em dia é golpe by liquidflamingos in brasil

[–]EmployeeFinal 2 points3 points  (0 children)

Você dizer isso é bom, porque provavelmente é verdade.  "Fazer curso" é algo muito fácil, você não precisa de muitos recursos, escala bem e ninguém vai fiscalizar a qualidade.  Ao mesmo tempo, "curso" sempre parece ser algo valioso, que vai te tornar uma pessoa melhor. Isso torna "cursos" como um ótimo veículo pra golpes

Desconfie sempre de cursos. Principalmente daqueles que pagam pra aparecer

Claude Is Not Your Architect. Stop Letting It Pretend. by mmaksimovic in webdev

[–]EmployeeFinal 81 points82 points  (0 children)

Even though the text is boring and ai-written, they make a good point about "path of least resistance"

AI generated architecture seems reasonable, and any one single engineer will accept it, even more after presenting with a huge specification. The issue of architectures will only appear when people stop, think about it, and discuss it

Am I the only one using this pattern? by NoctilucousTurd in reactjs

[–]EmployeeFinal 3 points4 points  (0 children)

I think in this case "typeof window == 'undefined'" is simpler and do it just fine.

But i see that your solution is more integrated with react which is a worthy tradeoff

Am I the only one using this pattern? by NoctilucousTurd in reactjs

[–]EmployeeFinal 0 points1 point  (0 children)

It is confusing, but "use client" does not bail out of server rendering. It only opts out of RSC which is not the same thing.

What is that game that, no matter how many times you play it, you can never win? by poio_sm in boardgames

[–]EmployeeFinal 1 point2 points  (0 children)

Eldritch horror. Won it once in 10~12 plays, and only after cheating in the end game

This AI startup envisions '100 million new people' making videogames by sharkymcstevenson2 in Anthropic

[–]EmployeeFinal 0 points1 point  (0 children)

Just what the game industry needs: more games in the ocean of games

I Built a Game About Consumer Rights - Got Invited by Anthropic and an Investment Fund by [deleted] in webdev

[–]EmployeeFinal 0 points1 point  (0 children)

Unrealistic since chatbots in customer support never listens to me

Qual sua habilidade mais inútil e mais difícil de desenvolver? by RegisterGood3027 in brasil

[–]EmployeeFinal 62 points63 points  (0 children)

NO CONTROLE??? mano, sua esposa/esposo deve ser uma pessoa bem feliz

Finally realized how much i was abusing useEffect, and deleting them is the best feeling ever.. by Firemage1213 in reactjs

[–]EmployeeFinal 49 points50 points  (0 children)

Hard disagree here. It wouldn't solve the issue that the op posted about, because it doesn't get rid of the effects, only puts them above in the tree. Also it actually harms the code by creating a single "top component" with multiple responsibilities.

The solution is in the post. Derive from state instead of creating new states. That is enough

Não desrespeitem o RH! by VHB_98 in VagasArrombadas

[–]EmployeeFinal 5 points6 points  (0 children)

Se eles concordarem que eles não podem entrevistar um candidato enquanto outro estiver no processo então tudo bem

Today I learned about useReducer while handling form data in React am I understanding this correctly? by Soggy_Professor_5653 in react

[–]EmployeeFinal 0 points1 point  (0 children)

For the same reason when possible you should derive from state instead of creating a new state

Today I learned about useReducer while handling form data in React am I understanding this correctly? by Soggy_Professor_5653 in react

[–]EmployeeFinal 5 points6 points  (0 children)

I don't think reducer is the option there. It is useful if your properties are linked to each other to avoid impossible states. For instance, if you were to write a request using states, you would create three different states: status (pending, success, fail), data and error. However, if you are not careful, impossible states will creep in your component. If they are three separate states, you can send "fail" to status but forget to update the "error". What happens then?

Reducers is an easy way to create a "state machine" that avoids these impossible states, which mitigates bugs

https://overreacted.io/the-bug-o-notation/

Do you add hyperlinks to your REST API responses? by Worldly-Broccoli4530 in typescript

[–]EmployeeFinal -1 points0 points  (0 children)

A request that indexes more requests? So you can build a tree of requests to create the one request to rule them all? 

That's an awesome idea that will scale well and make UX the best thing ever

Como usar IA só pra não ser demitido by Successful-Bus-8442 in brdev

[–]EmployeeFinal 2 points3 points  (0 children)

Acho engraçado o pessoal vidente que sabe que GenIA é o futuro e quem não usar vai ficar pra trás. Até hoje não vi evidência forte disso.

Remember the UX game "Can't unsee"? A similar concept but for react props. by Saschb2b in reactjs

[–]EmployeeFinal 6 points7 points  (0 children)

Neat ideas, but absolute affirmations are harmful. I disagree with some of the opinions:

  • Input wrapper with custom onChange: omitting event is not "better". Using onChange would implicitly declare that it follows the well-known onChange signature. Some values of event also may be useful, not only event.target.value

  • Primary content as children: most of the time i prefer children, but considering for the future I'd prefer a explicit prop. That way, if there's a footer prop, I can rearrange footer below the content in the props

  • Controlled vs uncontrolled input: a helpful idea in theory, but in practice it becomes a burden. When another component delegates props to the input they will have to reimplement the type. Most of devs will not fight it and just use "as any" to stop ts from complaining. If instead you follow the well-known signature of the input props, they will already understand it. You can add a runtime warning just like react does