Yes but given IteratorResult my impression is that T is going to be union of the dependency types-so how would TypeScript check for the correct cardinality and ordinality of the dependencies?
Thant's why I'm using branded interface (nominal typing) so that I can 'add' or 'subtract' from a union of literal string (or object with literal string type field).
I also suspect that a minority of Developers are fluent with generators so that may present an additional cognitive barrier.
I thought it's not typical generator function but more like a DSL. And in theory it's closer to Algebraic Effects (or Effect Handling) so that generator only provides the capability to interrupt the control flow. Just borrowing the syntax, I'm not expecting (dev) users to fully understand generator (unless they want to hack into low level implementations).
My personal experience has been that generators can be slow so it would be unfortunate if that would impose a premature performance ceiling
Only one-shot execution. Much better than react's repetitive render call (and repetitive closure creation).
apart from the concern that generators are a runtime mechanism that may prove impossible to streamline with some design/compile time generated injection scripts.
they are likely different concerns. i'm not requiring devs to replace their every function with generator ones.
Has it dependencies on a particular JavaScript runtime (e.g. browser vs. node; hopefully not)?
Does it have the potential to slow down microtests (> 100ms)?
negative. if generator is thought to slow down executions, they only affect the construction process (which only happen once). I don't believe this will dramatically affect the performance.
Does it impede the ability to test relative small units of capability (hopefully not)?
not at all. it's one of the design goal.
It really boils down to how easy (and fast) it is to test (I'm not keen on the React/Jest situation).
it should be as easy as test against a regular class object (after all I'm utilising generator to implement an atypical "constructor" that handles DI and provide dependency type inference).
Would const [count, setCount] = yield* State(initCount); actually work if it was run/tested independent from React? (seems UI would have to thread useState into App; one of my beefs with hooks it that they rely on a React specific mechanism).
exactly. it's a stand-alone fine-grained reactivity impl (similar to solidjs)
it's the Component((_,$)=>...) API connecting two worlds. UI is a branded interface for React.FunctionComponent (from a top-down view, UI is the last (ultimate) concern (matches UI as an afterthought); from a down-top view, UI is the most concrete thing you can start with, and you can implement everything inside initially then move things out gradually). React is agnostic to anything else.
I'm think about a proper naming of this kind of framework because it's different from any kinds of existing ones. I had a idea kernel framework (from Functional Core Imperative Shell, that the UI frameworks frame the shell while kairo frames the core)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thant's why I'm using branded interface (nominal typing) so that I can 'add' or 'subtract' from a union of literal string (or object with literal string type field).
I thought it's not typical generator function but more like a DSL. And in theory it's closer to Algebraic Effects (or Effect Handling) so that generator only provides the capability to interrupt the control flow. Just borrowing the syntax, I'm not expecting (dev) users to fully understand generator (unless they want to hack into low level implementations).
Only one-shot execution. Much better than react's repetitive render call (and repetitive closure creation).
they are likely different concerns. i'm not requiring devs to replace their every function with generator ones.
purely ecmascript standard, purely runtime mechanisms.
negative. if generator is thought to slow down executions, they only affect the construction process (which only happen once). I don't believe this will dramatically affect the performance.
not at all. it's one of the design goal.
it should be as easy as test against a regular class object (after all I'm utilising generator to implement an atypical "constructor" that handles DI and provide dependency type inference).
exactly. it's a stand-alone fine-grained reactivity impl (similar to solidjs)
it's the
Component((_,$)=>...)API connecting two worlds.UIis a branded interface forReact.FunctionComponent(from a top-down view,UIis the last (ultimate) concern (matches UI as an afterthought); from a down-top view,UIis the most concrete thing you can start with, and you can implement everything inside initially then move things out gradually). React is agnostic to anything else.I'm think about a proper naming of this kind of framework because it's different from any kinds of existing ones. I had a idea kernel framework (from Functional Core Imperative Shell, that the UI frameworks frame the shell while kairo frames the core)