Optimizing XState for production environments #1458
-
I searched around the issues and discussions and could not find an answer to few questions I have around I already wrapped the new import { inspect } from "@xstate/inspect";
if (process.env.NODE_ENV !== "production") {
inspect({ iframe: false });
} With the new inspector I don't see many reasons why one would not want to set One further idea I have around this topic I would love to hear your opinion about:I think it would be useful to have a global configuration ability to configure |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
It probably has a minimal impact; what it does is notify listeners that services have been registered on a global
I thought this at first too, but what if you're using 3rd-party components that are using XState? Enabling this globally (and having to opt-out) is not a good idea for this reason, and it's less explicit. The only benefit this would give is a very slightly improved developer experience, and for that, you can easily have a wrapper like this in userland: const interpretDev = machine => interpret(machine, { devTools: true })
.start();
// Replace:
// const service = interpret(machine);
// With:
const service = interpretDev(machine); |
Beta Was this translation helpful? Give feedback.
It probably has a minimal impact; what it does is notify listeners that services have been registered on a global
window.__xstate__
object, if it exists. If it doesn't exist, it does nothing. Still, it's better to set it tofalse
in production, especially for security purposes.I thought this at first too, but what if you're using 3rd-party components that are using XSt…