You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #83, I think it would be useful to use the TS code generator to create reusable libraries of components. This should only require some minimal changes to the generated code. We'd have to:
Add the "export" keyword in front of the class definitions for generated Reactors and Apps (top level reactors). So
class Foo extends Reactor {
becomes
export class Foo extends Reactor {
Don't generate the code to instantiate the top level App and start it. Since JavaScript modules are executed when they're loaded, we wouldn't want to accidentally start an instance of App each time the library is loaded.
It should be safe to do (1) and always generate reactors with the export keyword, regardless of whether or not the generated file is intended as a library. But we'd need to add a target property such as "Library" to tell the code generator when it should do (2).
Any thoughts? Maybe the "Library" property would be a good way to handle #83 too?
The text was updated successfully, but these errors were encountered:
Related to #83, I think it would be useful to use the TS code generator to create reusable libraries of components. This should only require some minimal changes to the generated code. We'd have to:
class Foo extends Reactor {
becomes
export class Foo extends Reactor {
It should be safe to do (1) and always generate reactors with the export keyword, regardless of whether or not the generated file is intended as a library. But we'd need to add a target property such as "Library" to tell the code generator when it should do (2).
Any thoughts? Maybe the "Library" property would be a good way to handle #83 too?
The text was updated successfully, but these errors were encountered: