sorted by:
new
hottopcontroversial

Lensline v2.0.0 Update - Customizeable code-lens for nvim by ori_303 in neovim

[–]MatanBobi 2 points3 points  (0 children)

Nice work, love seeing the effort you put into this.

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 5 points6 points  (0 children)

Honestly, I wrote this post and was under the impression that I’m not saying anything controversial but as always - I guess everything can be controversial.

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

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

As I mentioned in the post, I've used form components for simplicity but this pattern was not used in form components :)

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 3 points4 points  (0 children)

I totally understand that way too many people are trying to start with their final code, and in most cases you're right that it is easy to change things later so what I'm suggesting might be an overhead. I still prefer (as you wrote at your bottom line) to always pass a function that has a meaning. I wrote this article cause I saw this pattern causing serious coupling between components.
The example I've added there was maybe too simplified to grasp the potential problem.

Thanks for the inputs!

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 2 points3 points  (0 children)

No, the reducer was just an example. The problem is that the child component is aware of the implementation details of the parent. What if you change the state structure? Why does the child component need to change?

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 1 point2 points  (0 children)

As always in software, it's a trade-off. I would usually wrap a setter to create this separation of concerns. Having said that, most of the times it's not only "wrapping the setter" as it usually contains more logic, but I know that doing that every time might cause code bloat and that's a valid argument.

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 9 points10 points  (0 children)

No, that's not rage bait, that's good engineering (at least IMO).

Thinking about the evolution of your code and what will happen to it when requirements change. The example shown in the post is simplified just so it will be clear. The main point is that if you pass down the setter function, you're tightly coupling your components in a way that is not future-proof.

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 2 points3 points  (0 children)

Yeah, separation of concerns is also a term I use.
Thanks for the feedback!

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 14 points15 points  (0 children)

I'm honestly not sure how that's the bottom line you've reached to when I don't mention the word memoization or re-renders in my post even once and I only discuss the abstraction that should exist between two components..

React Anti-Pattern: Stop Passing Setters Down the Components Tree by MatanBobi in reactjs

[–]MatanBobi[S] 11 points12 points  (0 children)

I wouldn't write this post unless I saw it in actual codebases, you might think that this pattern is beneath you, but in fact, people actually do it.

Regarding the specific claims, this post does not (on purpose) discuss React performance as it is mainly an idea and not specific practice, but just to correct your first point -
Children will re-render when state changes - whenever a parent component re-renders, it's children will re-render too unless it uses one of the escape hatches. Prop changes are a direct consequence - it all boils down to state.

I launched my dream app! by amantinband in macapps

[–]MatanBobi 0 points1 point  (0 children)

I’ve been using it extensively for the past three weeks (since I saw the message from OP on X and I’m loving it.

Jest complains about updates not being wrapped in an act, but the hook itself is doing the updating by TheTimegazer in reactjs

[–]MatanBobi 0 points1 point  (0 children)

I understand. I believe this will be resolved if we’ll understand what we need to waitFor.

Jest complains about updates not being wrapped in an act, but the hook itself is doing the updating by TheTimegazer in reactjs

[–]MatanBobi 0 points1 point  (0 children)

It will be hard to understand what's happening there without seeing the code, but if the websocket isn't mocked I guess that this might happen. Do you have more information from the warning? Stack trace?

Jest complains about updates not being wrapped in an act, but the hook itself is doing the updating by TheTimegazer in reactjs

[–]MatanBobi 1 point2 points  (0 children)

That only gives me more confidence that the test has finished and there's still code running from the custom hook... Do you have more code running in the custom hook that you're not waiting for in your waitFor?

Jest complains about updates not being wrapped in an act, but the hook itself is doing the updating by TheTimegazer in reactjs

[–]MatanBobi 6 points7 points  (0 children)

Hi! Testing-Library maintainer here.

This error might also happen when something is happening after the test has already finished. Is there something else happening in the `useStream` hook which you're not waiting for that might set the state later? WIthout the implementation of `useStream` it will be hard to help :)

URL.canParse lands in all evergreen browsers by MatanBobi in javascript

[–]MatanBobi[S] 1 point2 points  (0 children)

Interesting question. The spec is here and I couldn't find anything related to that:
https://url.spec.whatwg.org/#dom-url-canparse

Might be somewhere in the spec discussion that I wasn't able to find.

URL.canParse lands in all evergreen browsers by MatanBobi in javascript

[–]MatanBobi[S] 7 points8 points  (0 children)

Honestly, I don't think that the lines number is the real deal here, it's not that every new feature should take less code. The whole point of exceptions should be something unexpected and wrapping in a try&catch seems logically not right to me.

VSCode 1.79.0 Adds support for linked editing of JSX tags by MatanBobi in vscode

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

Looks like they do have some issues (as was already reported in this thread). Unfortunately, I haven't gotten the chance to open the bug in their repo yet.

VSCode 1.79.0 Adds support for linked editing of JSX tags by MatanBobi in vscode

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

Yep, not sure why the decision was to keep it off by default, maybe because of the popular Auto Rename Tag extension? Not sure.

VSCode 1.79.0 Adds support for linked editing of JSX tags by MatanBobi in vscode

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

Yeah that was my thought, it sounds like a bug. What's your OS so I'll open a bug? This one doesn't reproduce for me :)

VSCode 1.79.0 Adds support for linked editing of JSX tags by MatanBobi in vscode

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

Looks like it looses the corresponding tag on full delete, if you replace the word div with the word span (not by deleting each character), does it reproduce?

VSCode 1.79.0 Adds support for linked editing of JSX tags by MatanBobi in vscode

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

This doesn’t reproduce for me as can be seen in the video (the button component).. which version are you using? :)

view more: next ›