| Some feedback on the API design and README: - Having a global registry of machines does not scale. Anyone building an app won't want to deal with the name conflicts. Having a `displayName` for debugging is fine but that's all. Having people pass the Machine instance to transitions directly is much more reliable/scalable. - This [...rest] for event handlers is not good. Put those in a dedicated object because if you don't any new prop you add has the potential to break users. It's also bad because it looks like memory gets merged with those methods, making it likely the keys will conflict in view(). - Find a better name for T, it's confusing with Transition. Since it looks like a simple struct, maybe just have people pass {name, to} as plain data. - You don't provide a rejected Promise example. I am interested how that works since it is something people tend to overlook. - How the heck do I test my machines? - A micro-framework that doesn't mention byte-size? Probably worth adding that statistic. My idea of a micro-framework is one that fits in a tweet. - Write up how you expect this to be used. I don't think you could use this to build a real app because there's no way compose machines, only switch between them. You'd end up with huge machines because UIs are trees. Happy to discuss more. |