This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-02
Channels
- # 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)
I have using this one approach https://github.com/funcool/potok
@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...
@niwinz nice re potok, that’s the stuff from uxbox, right?
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
well then 🙂
@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.
@jwr have you by any chance taken a look at the Riot client (as linked above)?
@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.
With a pluggable version of Sablono you would be able to use any framework you like. e.g. https://github.com/skatejs/skatejs, https://github.com/google/incremental-dom, Inferno, etc.
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 😄