Laminar Progress & Status

[raquo]

At current scale, a simple github issue will do for this.

[raquo]

I'm currently working on implementing a sample TodoMVC app. It is a good way to exercise most common use cases and pretty much the entirety of Laminar's API surface in a very small package.

As a result of this exercise I've been upgrading Laminar's API both for improved usage convenience and adding new features, including some very major upgrades. Some of the new stuff, in no particular order:

• Introduced the concept of Event Bus (onClick --> myEventBus instead of onClick --> myStream)
• Added more ways to subscribe to node events
• Reorganized the internals to support all of the above
• Added new functionality such as FocusReceiver to focus or blur elements
• Added new functionality to XStream.scala

I'm currently implementing proper node lifecycle hook system (mount / unmount / parent-change), which is a prerequisite for the milestone feature that I want to define v0.2 – automatic stream subscription management.

Currently when you unmount a node, it properly unsubscribes from the relevant streams. However, if you call myStream.subscribe manually, you need to remember to unsubscribe when you're done, or else you risk memory leaks and unintended behaviour (it' not a Laminar "feature", it's just how streams work). However, 99% of the time the desired lifecycle of stream subscriptions matches the lifecycle of "components" (i.e. nodes), so it should be possible to automate unsubscription in most cases, with an easy override if needed.

So far I really like where Laminar is going. I will publish the TodoMVC example together with v0.2 of Laminar.

[raquo]

FYI, All my next-version changes are piling up in the next branch.

I've just finished implementing and testing the lifecycle event system. Pretty happy with how it turned out, but I haven't had a chance to use it yet (other than to auto-plug memory leaks).

I wrote a sizeable chunk of documentation on how it works, see the README file in that next branch if you're curious.

Next up is better subscription management (what I described in the previous post). For the MVP I'll try to get the safety first, and then minimize verbosity as a bonus. I suspect that I will need macros similar to what scala-rx uses to reduce verbosity to the full desired extent, but I don't want to go there in the MVP, that can always be improved later.

[raquo]

I've just reworked how the event system works, and documented the whole thing. README is getting so long I need a table of contents already.

Next up is documenting how the various subscriptions works, so basically all the fun things you can do with <--.

Might also briefly document recommended component structure focusing a bit more on Laminar's ideology, and proposed input / output API decisions.

Then some time next week will hopefully get to implementing automatic subscription management. Everything is ready for it but I'm really annoyed by lack of documentation right now.

Also, I decided I will merge the next branch into master before I publish the unpublished dependencies that it requires to build. It's more useful that people see the new much more complete README on the project's front page than that master compiles for everyone at this moment, since Laminar is still a work in progress.

[raquo]

Just released Laminar v0.2, yays!

Apart from a ton of new and reworked features compared to v0.1, there is also a significant amount of documentation in the README for almost every single piece of functionality.

Will be getting to work on v0.3 soon, with the primary focus being on automatic subscription management for non-Laminar subscriptions.

[raquo]

I evaluated my options with regards to owner-bound subscriptions and state management solutions, and decided that I won't be happy with any available solutions (see #5 and the links from there). Typical streaming libraries just don't map well to what we need for Laminar.

So I started work on Airstream, my own state & streaming library that will be designed specifically for the hierarchical ownership + unidirectional dataflow model of UI components. Progress reports on that endeavor are in PR #8. So far the results are very promising, but there is much work ahead (sigh).

If this fails I guess I'll fall back to my original plan of modifying my XStream.scala wrapper for my needs, but I'm really hoping that Airstream will solve my problems without introducing more pain.

[doofin]

I am using outwatch now which is quite similar and found this project recently ,I think the idea of getting rid of virtual dom is great ! I am also interested in implement a stream based ui library from bare metal (with your dom builder library as a wrapper for raw dom things), Would you like to recommend some articles on the internals of stream/observable/eventbus based ui library?

[raquo]

Check out some of the articles written by the author of XStream.js: https://staltz.com/blog.html

There's also the famous paper https://infoscience.epfl.ch/ record/176887/files/DeprecatingObservers2012.pdf

Scala.rx README has "Design Considerations" and "Related Work" sections which could be helpful: https://github.com/lihaoyi/scala.rx#related-work

[fdietze]

I'm also having some thoughts about getting rid of virtual dom. Would you guys be interested in a video chat?

[doofin]

Sure! Are you guys using haskell? I want to build a abstract model for this kind of a ui design pattern with haskell/idris/agda,which allows a more formal reasoning

[doofin]

I think the whole virtual dom and facebook's react thing actually put functional programming at wrong place,they claim to separate pure and impure things,but ui programming is in essence the art of doing async gracefully

[fdietze]

I'm not using haskell, but I'm open to learn new things.

[raquo]

@fdietze Let's do it! @doofin No, I don't use Haskell

[fdietze]

Great, I'm located in Germany (UTC+1).

[raquo]

@fdietze Let's coordinate this by email maybe? @doofin could you please send your email address to nikita@raquo.com?

[raquo]

@doofin You might want to also look into source code of Sodium. Although from what I can tell it uses WeakRef-s for memory management, which will cause memory leaks in Scala.js.

This book uses Sodium for examples, and alleges that Sodium does not suffer from FRP glitches. I haven't figured out how yet. Looking at their transaction logic, I suspect they might mean this only for observers (not the streams themselves), which should be somewhat easy to implement in any streaming library.

[doofin]

@raquo I have send a email to your address. I have some experience in category theory/abstract algebra but not so much practical knowledge about computer science in general,So currently I plan to start with the simpler discrete case of reactive programming rather than continous frp

[raquo]

This issue has served us well enough, I'm now closing it in favor of #13 which discusses features that will make it to the next v0.3 release.

[raquo]

As v0.3 is about to be released, we now have gitter for Laminar and AIrstream discussions:

https://gitter.im/Laminar_/Lobby https://gitter.im/Laminar_/Airstream

[doofin]

Great! Have this released to maven repo?

[raquo]

Airstream v0.1 – yes, Laminar v0.3 – not yet, almost there. I'm done with code changes, but need a few days to update the docs. I think you might be able to try 0.3-SNAPSHOT with jitpack resolvers? But then again, no new docs yet...