This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (29)
- # boot (65)
- # cider (12)
- # cljs-dev (8)
- # cljsjs (31)
- # clojars (5)
- # clojure (147)
- # clojure-austin (47)
- # clojure-berlin (1)
- # clojure-brasil (7)
- # clojure-russia (5)
- # clojure-spec (18)
- # clojure-uk (18)
- # clojurescript (113)
- # css (2)
- # cursive (7)
- # datascript (5)
- # datomic (2)
- # dirac (4)
- # events (3)
- # funcool (143)
- # hoplon (287)
- # jobs (2)
- # off-topic (4)
- # om (10)
- # om-next (5)
- # onyx (18)
- # protorepl (1)
- # re-frame (93)
- # reagent (34)
- # rum (41)
- # test-check (51)
- # untangled (15)
- # yada (18)
@janrychter I have some notes here: https://gist.github.com/martinklepsch/e1366008c5a478b33c00d324314da4fd
that is much simplier that reframe and carry but offers almost all that you going to need...
I’m a but cautious to pull in beicon/promesa/bluebird and all that but I’ll consider for a thing I’m currently working on
@niwinz mostly just not much experience with reactive stream stuff and it seems like a heavy dependency
@jwr BTW, the gist above uses re-frame (as you’ll see) but the form library itself is pretty much agnostic to that
@niwinz I pushed a few updates to
derivatives lately, I remember we chatted about it before: https://github.com/martinklepsch/derivatives / https://github.com/martinklepsch/derivatives/blob/master/CHANGES.md
@jwr I’m sending messages from the Slack #rum room which are bi-directionally bridged into Gitter and Riot via Matrix
@jwr that’s fair. I wanted to see how it works when bridging Gitter <> Slack <> Matrix and the Gitter integration is the one that is most interruptive in terms of how it looks to other users. Maybe we should disable that bridge again and only continue using the Matrix <> Slack bridge.
@nooga We have thought about it at my company. You would need to write a pluggable version of Sablono.
> Inferno allows people to switch their existing React projects to Inferno in a few lines of code using inferno-compat
https://github.com/infernojs/inferno#createelement-package-inferno-create-element. It’s very similar. I never dove super deep because we didn’t have a strong enough push for it.
The reason I was thinking Sablono would have to be pluggable instead of writing a wrapper for React’s API is to account for framework differences. With incremental DOM you have the ability to specify static attributes, so you would probably want a way to specify that via hiccup.
Theoretically, you would be able to mix and match the different frameworks. It’s not clear if a use-case for that would exist (maybe wanting to re-use React components inside an Inferno/SkateJS/etc app), but I think it would be possible.
porting your humongous project from one lib to a new one in 5 minutes would blew js people heads off 😄
Totally. It would just take some thought to make sure you got it right. It’s possible you would need to completely re-write sablono to be pluggable from the ground up.