Comment by tokyodude | Hacker News Reader

Comment by tokyodude | Hacker News Reader

Parent Full thread

Agreed. The "everything needs to be a react component" is bad IMO. My example, I'm making an image viewer. I want a context menu. IMO the ideal solution some generic right-click (context menu) function/handler. you attach it to each image. On right click the image is passed to the handler and the handler does something with it. That's relatively low overhead. There's no per image data.

But the React stuff I found made a context menu of nested components per image. Effectively <image><contextmenu><menuitem/><menuitem/><menuitem/><menuitem/><menuitem/></contextmenu></image>. For 1000 images that's 6 thousand components created, 6000 things added to the virtual dom to be diffed, 11000 considering the content of each menuitem is actually yet another dom node.

There's tons of react libraries like that where they try to shovel every concept into a component.

This just sounds like inexperienced programmers. I've played around with React and it doesn't seem like there is anything special about React that would prevent you from creating a single instance of a component and have it's state update based on what image you are right-clicking on.

In your example, the contextmenu component should not be created until the image is right-clicked.

So your <image> code would look something like this:

    return (<><img .../> {contextMenuActive ? <contextmenu>...</contextmenu> : null}</>);

> IMO the ideal solution some generic right-click (context menu) function/handler. you attach it to each image

Ideally, you would only have a single event listener that handles events for all images.

With React, it's one and the same thing. React has a single event listener at the top level, then creates synthetic events that it passes down the tree. You can still do native event listeners, but there's no reason to, except for listening for events on `window`, etc.

Look into portals https://reactjs.org/docs/portals.html. The menu should probably be owned by a shared component somewhere in the root of the tree, and then children can ask it to open via handlers propagated somehow (context, redux, whatever).

Reply on news.ycombinator.com