[core] Suggestion to fix eslint error with CodeCopy.tsx with immutable object

[wilhelmlofsten]

Suggestion for fix #42564 with CodeCopy.tsx.

So suggestion with using React Callback with passing the argument instead of directly and due to rootNode.current = node still being immutable (eslint error), can disable it with react compiler - saw that it was done previously in the code. So open for suggestions for this solution/ feedback to change the code! 😃

• [ x ] I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

https://deploy-preview-44348--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against ce3e799

[Janpot]

I'm not sure what we gain from this refactor, the code still contains an ignore directive, which means the whole file still doesn't get transformed.

I believe the canonical solution to this problem would be to expose the setNode in a context instead of the ref. But I could be wrong, I have just as little mileage with React 19 as the next guy 🙂

[wilhelmlofsten]

I'm not sure what we gain from this refactor, the code still contains an ignore directive, which means the whole file still doesn't get transformed.

I believe the canonical solution to this problem would be to expose the setNode in a context instead of the ref. But I could be wrong, I have just as little mileage with React 19 as the next guy 🙂

Yea noticed CI testlint failing now when i turned the eslintrc check back to false again with "// eslint-disable-next-line react-compiler/react-compiler" with now giving errors ..

I would argue that im still new to open source development and MUI project, so thankful for the fast feedback! Will look into exposing the setNode into the context instead with that seeming to be a more thoughtful approach! 😄

[Janpot]

yes, but even that, isn't this just a false positive in the eslint plugin? I assume it's only complaining because it can't infer that in fact rootNode is a mutable ref.

[wilhelmlofsten]

yes, but even that, isn't this just a false positive in the eslint plugin? I assume it's only complaining because it can't infer that in fact rootNode is a mutable ref.

Yeah, that makes sense - it does seem like a false positive, especially since setting eslint.rc to false resolves it. And yes, rootNode is indeed mutable. Should we consider adjusting the ESLint configuration if the inline comment isn’t working as intended, or how should we proceed forward?

[wilhelmlofsten]

Suggested push from feedback from @Janpot with:

• changed setRootNode to setNode (my previous pr commit)
• exposed the setNode inside the CodeBlockContext and passing arguments to setNode directly
• added useMemo to prevent rerendering inside the codeCopy provider with contextValue

This removed the eslint error and tested it with compiling and used codeCopy and seems to work 😃

So open for feedback/suggestions/ Reviews!

[wilhelmlofsten]

Hello! Is there an update or possibility to get a review @Janpot @aarongarciah :)

[Janpot]

I believe this will result in extra renders each time setNode is called. Renders that wouldn't happen with the useRef implementation. I think a more correct implementation keeps the ref and instead only passes a setNode callback in the context.

const rootNode = React.useRef<HTMLDivElement>(null);
const setNode = React.useCallback((node) => {
  if (typeof node === 'function') {
    rootNode.current = node(rootNode.current)
  } else {
    rootNode.current = node
  }
}, []);

// ...

<CodeBlockContext.Provider value={setNode}>

That being said, I'm still not convinced we should do this refactor at all. Maybe we should work on the motivation first?