PixelPicoSean Posted January 4, 2016 Share Posted January 4, 2016 >Because creating, modifying, or in any way changing DOM is expensive. I think I understood what was wrong with this conversation. No, I am not talking about this aspect of virtual dom.If you use FRP approach, it is much easier to recreate the whole UI every change of the state instead of modifying UI directly.So, I need to recreate the whole UI object model.For example if I have timer, then render function always return new text object.render time = h("text", {text: time})and it is completely different from the common approachvar timeText = new PIXI.Text();changeUI time = timeText.text = time;That is why there are two options1) I can recreate the whole Pixi object model2) I can recreate the whole virtual dom object model.Virtual dom model is much lighter than Pixi model.So it is preferable to work with virtual dom, compare two states of it, and apply diff to the real Pixi dom.It isn't because I think changing the Pixi dom is expensive.It's because I need to recreate the whole object tree after every change.Is it clear now?I actually use FRP concept in all my games, for not only UI related behaviors but complex states management (think about FSM without a traditional API). It does not actually require any external libraries since Pixi objects are also EventEmitters which performs just like those DOM objects. What you need to do is simply use them as stream sources. And FRP concepts work pretty well without any virtual-dom stuff, I'd recommend to try and find the best way for your own. BTW I use Kefir.js with Pixi for FRP support which is not perfect but still great for most cases. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.