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
{{ message }}
This repository has been archived by the owner on Dec 25, 2018. It is now read-only.
Our hooks have correct types except for one edge case, when the hooks for the initial app container are processed. Snabbdom creates a virtual empty node for the first argument of patch method when it's a real DOM element, and that empty virtual node is not an instance of our own Node class but a plain JS object which although has a similar shape will be missing any additional fields and methods defined in Scala. This is especially a problem for libraries based on Snabbdom.scala that subclass Node and NodeData.
There are a couple ways to fix that. One is to make the types reflect this reality. Another is to keep current types but avoid calling Scala-provided hook on the snabbdom-created node in that edge case.
I kinda favour the latter option because we will probably not lose anything of significance, but it would be a departure from Snabbdom.js API, so needs to be considered more carefully. Which is why this is not yet resolved.
The text was updated successfully, but these errors were encountered:
Our hooks have correct types except for one edge case, when the hooks for the initial app container are processed. Snabbdom creates a virtual empty node for the first argument of
patch
method when it's a real DOM element, and that empty virtual node is not an instance of our own Node class but a plain JS object which although has a similar shape will be missing any additional fields and methods defined in Scala. This is especially a problem for libraries based on Snabbdom.scala that subclass Node and NodeData.There are a couple ways to fix that. One is to make the types reflect this reality. Another is to keep current types but avoid calling Scala-provided hook on the snabbdom-created node in that edge case.
I kinda favour the latter option because we will probably not lose anything of significance, but it would be a departure from Snabbdom.js API, so needs to be considered more carefully. Which is why this is not yet resolved.
The text was updated successfully, but these errors were encountered: