Closed germain-gg closed 5 years ago
I like the docs you've written for the Custom Source Node. And I think you're right about lack of non source-node usecases.
I feel like I am missing documentation and a proper SourceNode interface. Any suggestions as to where I could add that?
Do you mean documentation on how the SourceNode is used and documentation of the public API? Or documentation of the private API (which would be super useful for contributors) that you may need to use when creating custom nodes (and notes warnings about breaking changes).
I may have forgotten where we go to with this, but should users need to rely on internal APIs (like _load
) when writing custom nodes. Or should they be able use the event callbacks instead?
I think both a documentation for internal or public API would be useful.
One of the thing that the project is lacking is a properly defined interface for Nodes. I know that TypeScript brings that concept to JavaScript but that's also quite a lot of work to introduce that here.
I might start another markdown document that will explain what methods a custom source node should implement and what events exists and when they should be triggered.
Thanks for the heads up with the typo. I'm planning on finishing that before the end of the week
I might start another markdown document that will explain what methods a custom source node should implement and what events exists and when they should be triggered.
That sounds great. Would you like me to merge this PR, or leave it open waiting of these docs?
Happy for you to merge it! I'll create another one when I get to that bit 👍
This PR follows up on the issue #115 and will help achieve #19 without increasing the video context footprint.
On the issue we were talking about creating a factory function where we can pass a video context instance. After thinking about it a bit further I found a few issues with that approach.
Essentially when creating a node we rely on some vc internal
_gl
_renderGraph
_currentTime
By going with the approach that I propose in this PR I feel like the custom types will be less likely to break in case of a breaking change in the naming of one of those internal properties.
I could not find any use case to create a custom node type that is not a source as
EffectNode
are already super generic and let you pretty much do everything you want by giving a custom definition when you instantiate them.However for sources I could thinking of the following use cases:
libgif
on npm) and display the GIF frames by hooking into the_update
functionI feel like I am missing documentation and a proper
SourceNode
interface. Any suggestions as to where I could add that?