alexgalays / kaiju

Fast Virtual DOM components with Reactive updating

kaiju's Issues

Event listeners are not removed when using message.with(newReference)

click: myMessage.with({})

then

click: myMessage.with({})

= Two event listeners are registered against the click event.

Fullpage application problem

I used snabbdom at the moment to build application which able to attach to document.documentElement. Also this app compatible with server-side rendering. So it renders root page tree starting from html node. Snabbdom works fine for this case, but I failed to start application using kaiju. The problem of kaiju in that by default it append child to node and don't provide any ways to attach to node itself.

snabbdom modules parameter in startApp is redundant

Snabbdom modules parameter when calling startApp is redundant, why not require all the modules and pass them to the snabbdom init instead.

Simplify Message vs DefaultMessage

Right now, it's a bit of a mess. The Message type sometimes has to be used, sometimes we need to use DefaultMessage. Same with NoArgMessage(s); all this just to make the type system happy so that dangerous combinations are not used.

This comes down to Bound messages (using with()) and the fact that some messages will deliver an Array, some others a scalar and there is no way to know which is which at runtime.

In order to fix this, we can abandon Arrays and declare multi arg Messages like so :

const message = Message<number, MouseEvent>('click')

Can't do msg.send synchronously inside connect()

It throws:

snabbdom subtree render

Hi,

I've seen many discussions now about rendering subtrees in snabbdom, and the best lead seems to be kaiju's source code. Is the patching code something that we could extract somehow so it's available to all snabbdom users? I might even be on the wrong track since I'm not that sure of what and how kaiju makes the patching of subtree vNodes. Could you help shed some light for us?

Integrate jsx

Do you have any plans to integrate JSX into this project (I think that can increase the popularity of this framework)?

Observable.filter has a wrong type signature

The signature prevents it from correctly inferring the callback type.