This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-26
Channels
- # admin-announcements (1)
- # beginners (167)
- # boot (117)
- # boulder-clojurians (1)
- # cbus (1)
- # clara (3)
- # clojure (87)
- # clojure-conj (2)
- # clojure-japan (2)
- # clojure-russia (23)
- # clojure-spain (3)
- # clojure-za (2)
- # clojurescript (184)
- # community-development (8)
- # core-async (7)
- # core-matrix (4)
- # cursive (36)
- # data-science (74)
- # datascript (3)
- # datomic (171)
- # events (6)
- # hoplon (83)
- # ldnclj (5)
- # ldnproclodo (1)
- # lein-figwheel (2)
- # leiningen (19)
- # liberator (2)
- # off-topic (5)
- # om (227)
- # onyx (5)
- # re-frame (142)
- # reagent (4)
- # yada (5)
@jelz has done some fine work creating a re-frame version of the flux-challenge. If any of you experienced re-framers have time, please give feedback: https://github.com/Day8/re-frame/issues/126 (I've asked jelz to come here for that feedback, but I'm not sure what his circumstances are, and if that is possible).
It looks like a fun little exercise (I wish I had more time for it right now)
I'm guessing there's a better way to center something horizontally:
(defn center [form]
[rc/h-box
:size "initial"
:children [[rc/box
:size "auto"
:child " "]
form
[rc/box
:size "auto"
:child " "]]])
First adjustment might be (untested):
(defn center [form]
[rc/h-box
:size "initial" ; needed ???
:children [[rc/gap :size "auto"]
form
[rc/gap :size "auto"]]])
But an easier way might be ...(defn center [form]
[rc/h-box
:size "initial" ;; needed ?
:justify :center ;; <----- new
:children [[form]]])
Summary: look at the justify
parameter.
Don't trust the code above ... its been a while since I had to play with re-com so I might be forgetting something.
Hello everybody, I believe that I've already been mentioned here: https://clojurians.slack.com/archives/re-frame/p1445822732000398 I've just updated the ticket - as I stated there, it would be great if you could take a look and comment in this pull request.
The idea is to transform my code from "exercise of Clojure newbie" level to something that can be representative for re-frame
Has anybody successfully used devcards
with re-frame
? I ask because I am attempting to use devcards to demonstrate small, simple examples with re-frame. I thought I’d do this with via dependency injection. However, this is turning out a bit more difficult than I thought.
For example, https://github.com/Day8/re-frame/blob/e803659a56c7cca574f2d9d88df79307a0e52581/src/re_frame/subs.cljs#L26
I’d like to be able to inject my own database if I need to. However, there’s no hooks (is that the right term?) for me to do so.
I’d love to hear people’s ideas. Forking could be an option.
@kurtlazarus: you can dynamically replace re_frame.db.app_db as a quick hack, if you want more flexible approach, look at my fork: https://github.com/darwin/re-frame, with that you can implement something similar to scaffold.cljs on your side
@darwin: Thanks, I’ll take a look.
I’m also considering re-writing scaffold.cljs in a better way, without app-db and app-frame as global state, then it would be easier to reuse bits from there, just didn’t get to it, something along Stuart Sierra’s recommendations in component readme
"Encapsulate all the runtime state needed by the library in a single data structure. Provide functions to construct and destroy that data structure. Take the encapsulated runtime state as an argument to any library functions which depend on it."
Are there any other relevant pull requests?
@darwin: @tel I figure it would be good to pull the conversation in here.
I could see different run loops getting messy.
Maybe it would be something similar to Elm’s/ReactiveX’s philosophy?
why? each is its own isolated world which does not know anything about others, I think messy would be to have just one run loop and try to keep handlers and subscriptions for all devcards in one re-frame instance
as I noted in the cljs channel, the tricky bit is in "Take the encapsulated runtime state as an argument to any library functions which depend on it."
didn’t have that much problem passing context to reagent components I pass the context as normal param to render function
almost all functions get this first “context” parameter and have to pass it further down
I have a macro (tokamak/with-reactor rx …)
which “pulls” the context data structure from thin air (actually the react child context)
it’s a little unfortunate though because it creates a new react component just to capture the “reactor"
hm, interesting, but I don’t want to go down to react level if possible, I could do something like this using clojurescript tools
I already have this, so I could bind some global in run-queue here, and pull it when needed: https://github.com/darwin/plastic/blob/master/src/main/plastic/reagent/patch.cljs
this line calls update on specific component: https://github.com/darwin/plastic/blob/master/src/main/plastic/reagent/patch.cljs#L34
I originally tried doing this using (binding [*rx* …] (r/render …))
but that meant that the reactor was only bound during the initial render
but the person who actually renders the components will get final say in which reactor is in use
I was probably wrong, this run-queue does only updating of components which were marked as dirty
another idea: if you have just one app-db atom, you could set that context before doing reset!/swap! on that atom
reactions run from watchers on atom, so having that context set by that time should work
in case of official re-frame, you could do it in pure middleware
or in your own run-loop
the challenge, I think, is when a new component gets rendered it can’t know where to pick up the global db reference from if it needs it
haha, I should really just figure out how to do at least a beta release of this stuff instead of bantering around so vaguely
well, initial render is done after initial mount, isn’t it? so you would do the same thing before mounting
dunno, as I said, I’m passing the context all the way down as first parameter, so this is not really my problem ATM
my problem right now is having two re-frame instances, one running in main js context and a second one in a web-worker js context, they can dispatch events to each other, but sometimes need continuation, for example main thread asks for some work on worker thread and when that thing is about to be committed to worker’s app-db, it wants to be notified about results and finish some work on main thread before updating main app-db. basically I need both app-dbs to be in consistent state versus each other (eventually). so I can implement undo/redo on top of it.
oh, so perhaps I misunderstand, why not just have it throw back to the main when it’s done working?
usually, sometimes main thread just asks worker to update its state without answer back
main thread does renders it via reagent and manages some lightweight state, like cursors and selections
then as long as the main app has a read only stance w.r.t. that substate it shouldn’t trample anything
no, I’m afraid, it can’t easily, I cannot marshal whole data structure over the messaging channel
I will just have to be careful and keep good track of which pairs of app-db are suitable for undo snapshot
and depending on where the work happens could totally negate the purposes of the webworker
well, I have a debug mode which runs both in main js context (optionally without marshalling)
I think the pure state transformer bit could be extracted as well, which could be sort of appropriate for web worker situations
thanks, I strongly believe someone already tackled something like this and there is a good theory about it somewhere
maybe I should not do undo snapshots on worker at all, undo on main thread should “cause” some events to be fired on worker, to get back to some relevant state to match main app-db
in which case annihilating it all and rebuilding upon world changes like undo/redo feels reasonable
that’s another thing which always feels a little weird about re-frame since it’s global… the undo/redo effects are certainly “outside” of the application state
for example in my app-db I keep state of multiple code editors, it makes little sense to do undo on whole app-db
that is what I have now, I do complete snapshot of editor state and store it as vector
(defn historical [redu] (fn [state ev] (let [new (redu (get state 0) ev)] (conj state new)))
what makes better sense, is to prepare undo event, for each mutation event, but this is a lot more work and prone to breaking