Conversation
|
|
| subjects.get(key)!.next(propValue); | ||
| } else { | ||
| // Create new subject | ||
| subjects.set(key, new BehaviorSubject(propValue)); |
There was a problem hiding this comment.
A component might actually not want to subscribe to every possible prop. How about only creating Subjects/Behaviors when an actual call to .subscribe() is made?
So the check you did above, on line 55, may still hold and would fork fine, with the added benefit that we would not make unnecessary calls to .next() on any stream if here's no subscriber...
package.json
Outdated
| }, | ||
| "peerDependenciesMeta": { | ||
| "react": { | ||
| "optional": true |
There was a problem hiding this comment.
We probably don't want the whole library to pull in react (or other frameworks later on).
Was thinking about some alternative options:
- export this adapter as
rimmel/in-react, with its own package.json, etc.
convenient as it would be all in the same place, but the whole project could grow too large if we later add other adapters for other frameworks - create a completely separate and independent
rimmel-in-reactor@rimmel/in-reactpackage
maybe a bit less convenient to maintain, but would keep dependencies properly isolated
Option 2 appears a bit more appealing, unless there are even better ideas?
|
I addressed both concernes: 1. Lazy observable creation 2. Dependency isolation Migration for users: npm install @rimmel/in-reactTesting:
|
2 participants
Implements
WrapForReact()to enable seamless use of Rimmel components inside React applications.Features:
Usage:
Example included at
react-interopdemonstrating bidirectional reactivity.Closes #71