Gonna start looking at this when I get back tomorrow, but one thing I'm going to double-check is our state (limiting non-deterministic inputs so that renders stay pure) and effects (making sure everything has a cleanup function if it makes sense)

Did a quick scan for our currentuseEffect calls, and a couple of concerns jumped out at me. To be clear, I don't know if these should block enablingStrictMode. These are bugs that our tests aren't catching, but the point ofStrictMode is to highlight that these bugs exist. The issues still exist for the end user, whether we're usingStrictMode or not

• useProxyLatency
  • Doesn't clean up itsPerformanceObserver
  • Didn't read through the whole file, but my understanding is that each time the effect re-fires, we'll get a new observer that will keep updating state that we don't care about anymore
• MonacoEditor
  • Not sure if we want to cancel remeasuring the fonts when the theme changes
• TemplateVersionEditorPage
  • The TAR reader has a race condition when the data changes
    • Initialize the file tree for data 1 and kick off an async process for reading it
    • Data changes and kicks off a new effect, and we now do the same thing for data 2
    • Data 2 finishes reading and updates state first because it's shorter
    • Data 1 then finishes and updates state as well, writing stale data
• WorkspaceBuildProgress
  • Doesn't clear out a timeout

@Parkreiner how did you find those issues? I'm very interested if you have some methodology for that.

@Parkreiner how did you find those issues? I'm very interested if you have some methodology for that.

@BrunoQuaresma There's not really a methodology. All I did was do a search for the regexuse(?:Layout)Effect\((to find invocations instead of just import statements) and eyeballed the logic really quick

@Parkreiner I created a new issue to track those issues. I'll look into them tomorrow, but it'll be as a separate PR.