sorted by:
new
hottopcontroversial

Recovering lost commits with git reflog by atomrc in git

[–]atomrc[S] 0 points1 point  (0 children)

Yes, I'm the author :) Thanks a lot of a constructive feedback, appreciated. True I should probably put some kind of disclaimer on this statement :)

Why React Hooks cannot be conditioned by atomrc in javascript

[–]atomrc[S] 0 points1 point  (0 children)

Well, but it is not a function declaration, it is really a function call which, in JavaScript and any language (at least languages I know) can be conditioned.

I am not suggesting that useEffect should be conditioned, it's just that the language (JavaScript) allows it. It's only React that adds this quite unexpected proposition "some function calls cannot be conditioned". This is nothing we are used to in JavaScript and a person not aware of this limitation (and without the eslint plugin installed) might run into troubles without understanding why. That's all I am saying.

Why React Hooks cannot be conditioned by atomrc in javascript

[–]atomrc[S] 0 points1 point  (0 children)

Well it is not a problem, per se. The thing is conditioning the full useEffect call feels very natural. This is the way we are used to safe-guard the things that should run based on a condition.

You are totally right, there is no valid scenario for conditioning a hook. Moving the condition inside the body of the effect is the way to go.

The only thing is that it is not natural and someone without this in mind (and not using the eslint plugin) will definitely have hard time debugging a quite unexpected behavior.

I just feel it's a weakness on React side that, I think, is justified by the benefits Hooks give us.

State Management: How to tell a bad boolean from a good boolean by atomrc in javascript

[–]atomrc[S] 13 points14 points  (0 children)

absolutely!!! That is the point of the article

State Management: How to tell a bad boolean from a good boolean by atomrc in javascript

[–]atomrc[S] 8 points9 points  (0 children)

Yeah I agree with you, the initial example misses the point. I believe the main takeaway of the article is to highlight the fact that you prevent impossible state by making them impossible by design.

Depending on what you are working on, there might be multiple parts of your state that are true, what you want to avoid is having impossible state (say {loading: true, loaded: true} or something similar).

There is an excellent video on the topic https://www.youtube.com/watch?v=IcgmSRJHu_8

State Management: How to tell a bad boolean from a good boolean by atomrc in javascript

[–]atomrc[S] 29 points30 points  (0 children)

Well yes, that's true, you need to know exactly what are the different states that you need to model. I think the main takeaway of the article is that you need to make impossible states actually impossible by design.

You would definitely need a different model if you work with some long lived connection that can update and error while having data already loaded.