Comment by lelanthran

1 day ago

> Multiple times in the docs it compares a huge complicated JSX like component and replaces it with 3 lines of html and 3 lines of css.

I've seen my fair share of React code, and the code he is displaying is definitely idiomatic React.

> It could use less grand claims and focus more on what it really does.

Agreed. While I appreciate that a rationale is needed for something like this, I think his presentation of the rationale was far too verbose compared to diving into some code.

Maybe I'm not the target - I would have preferred more code and less pontificating, because I 'noped right out of React and others. What I have as a replacement in standard JS, HTML and CSS is unsatisfying to me.

5 comments

lelanthran

Reply
robertoandred  18 hours ago

> the code he is displaying is definitely idiomatic React

It's really not. There's nothing, for example, stopping you from using <dialog> in React. It works perfectly fine and can integrate with any state or event manager if you want it to.

What he's doing is comparing brand-new web features that don't have good support yet with long-standing solutions that were needed years before those web features were a glimmer in anyone's eye.

  • lelanthran  17 hours ago

    >> the code he is displaying is definitely idiomatic React

    > It's really not.

    Of the React projects I've seen (including a ton on github), none of them used the browsers dialog without a React wrapper.

    A quick search on google for a React project using `<dialog>` found none. Similar for github.

    If you have an example, I'd like to see a link, because I'm skeptical that React projects are using `<dialog>` without wrapping it in React.

    • robertoandred  17 hours ago

      I'm not sure what you're searching for or what you consider "wrapping it in React". You need some sort of JS to open and close it.

      const Modal = ({ isOpen, onRequestClose, ...rest }: ComponentProps<"dialog"> & { isOpen: boolean; onRequestClose: () => unknown; }) => {

        const dialogRef = useRef<HTMLDialogElement>(null);

  useLayoutEffect(() => {
    if (isOpen) {
      dialogRef.current?.showModal();
    } else {
      dialogRef.current?.close();
    }
  }, [isOpen]);

  return (
    <dialog
      ref={dialogRef}
      onClose={(e) => {
        e.preventDefault();
        onRequestClose();
      }}
      {...rest}
    />
  );

      };

    • lolinder  17 hours ago

      You're missing the main point that OP is making: TFA's complaint with these patterns isn't that it's React, it's that it's not using the modern tooling. That is true, but could just as easily be an argument for updating old React code bases to take advantage of the new features. There's nothing inherently React about avoiding using them, it's usually done because of some combination of lack of knowledge of the changes and a need for various reasons to support old browsers. (Yes, a lot of real world use cases still require supporting versions of Safari older than 15.4 [0]).

      It's not fair to take these legacy patterns, which are what made React and friends so much better than the other options that were available at the time, and compare them to features that were specifically built with the intention of making those patterns no longer necessary.

      Once those new features are supported on most devices (which again, they aren't in many cases) I'm excited to see them incorporated into code bases written in any framework.

      [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...