This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # aleph (1)
- # aws-lambda (14)
- # beginners (6)
- # boot (34)
- # carry (71)
- # cider (8)
- # cljs-dev (3)
- # cljsjs (3)
- # clojure (40)
- # clojure-belgium (1)
- # clojure-greece (182)
- # clojure-mexico (1)
- # clojure-poland (8)
- # clojure-quebec (1)
- # clojure-russia (72)
- # clojure-spec (30)
- # clojure-uk (120)
- # clojurescript (62)
- # cursive (3)
- # datomic (17)
- # euroclojure (5)
- # hoplon (26)
- # keechma (6)
- # mount (3)
- # off-topic (2)
- # om (5)
- # onyx (4)
- # other-languages (3)
- # parinfer (2)
- # pedestal (2)
- # planck (30)
- # re-frame (81)
- # reagent (31)
- # spacemacs (7)
- # spirituality-ethics (21)
- # testing (10)
- # untangled (80)
btw, we spoke about the
debugger-added? thing a few days ago, and you said the whole debugger code would be added in a production build if I use that function
but doesn't the closure compiler optimise imports in a way that only that function will be included, if it's all I use?
@kauko: I think that Closure compiler can't optimize it in a way you describe because it can't determine during static analysis that
debugger-added? would always return
false. My theory was that maybe you won't be needing
debugger-added? if code is restructured in such a way that debugger is not included in production build, e.g. if you have 2 separate build profiles and main files.
oh well, one solution would be that my "main" function will take a react component as a parameter, and it will either be nil, or the debugger
Maybe you could move view initialization code closer to the app spec definition (as they seem kinda coupled)? So that you don't have to determine if debugger was added in spec or not dynamically.
Added notes about usage with Devcards and REPL into User Guide: https://metametadata.github.io/carry/user-guide/#usage-with-devcards https://metametadata.github.io/carry/user-guide/#usage-with-figwheel-and-repl
the first time I read them I was confused whether Carry works with other view libraries besides Reagent (I asked about that on reddit)
:on-start/:on-stop signals are kinda orthogonal to Rum so you shouldn't have much trouble with them
I was thinking about simply back-linking to
carry-rum project in case you publish it (incl Devcards integration, server-side rendering and other docs)
@metametadata: @kauko regarding the
debugger-added? thing — if you use
:closure-defines with the proper type hint the compiler is smart enough to remove stuff that can't be reached
This might be helpful to understand the possibilities/getting started: https://www.martinklepsch.org/posts/parameterizing-clojurescript-builds.html
@kauko: If you're using carry & rum how are you handling the view model aspects? I made a little thing to help with that (not specific to carry) which I'd be interested in getting some feedback on
but I guess I misunderstood your question, what does the number of view-models have to do with this? 🙂
In re-frame I've had many subscriptions with different data in different forms, I guess in carry you'll similarly end up with multiple view models which are tailored to the situation you want to use them in. Carry's spec based approach inspired me to try doing something similar to subscriptions/view-models which lead me to something like this: https://gist.github.com/martinklepsch/c5a2feacc63ce08565fcffe37951ab64
There's a lot of documentation missing from this but essentially 1) take a component/system like spec and create a bunch of derived-atoms based on the dependency information 2) provide a rum mixin that puts functions into
childContext which can be used to
release! these derived atoms, essentially acting like a resource pool (while allowing multiple resource users) 3) provide some sugar to use the functions in the component context
Hmm, I'm not sure I really grasp what problem this solves. Carry's view-models are optional, they just get the model and return data that the view cares about, with a structure the view understands.
Actually that got me thinking, don't pretty much all components have to take the whole model as a parameter anyway if they have child components? Unless you want the component to care what kind of data the child component takes
The problem this solves is creating inter-dependent view-models (similar to re-frame's dynamic subscriptions) and getting them to the components that need them
Hmm, I'm trying to use the
carry-atom-sync with devcards, but the data inspection / history stops working after one interaction
@martinklepsch: when you use term "view-model" do you mean a single derived atom (akin to re-frame's subscription) or a bunch of atoms? In Carry+Reagent view-model is usually a map of multiple reactions.
Carry's view-model kind of corresponds not to a single re-frame's subscription, but to the set of subscriptions.
>Actually that got me thinking, don't pretty much all components have to take the whole model as a parameter anyway if they have child components? Unless you want the component to care what kind of data the child component takes It depends on the type of component. You can have top-level container/smart components which take in a reactive view-model (or a bare model if don't want to bother with vm layer) and also more reusable presentational/dumb components like a "button", "report-graph" etc. which have static props. This dichotomy is described in this article by Dan Abramov: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
it works fine if I use a hacky version of
carry/app that takes the model-atom as a parameter
yeah, I think that's the problem - I can reproduce your issue when after switching to
:watch-atom false option seems to fix the problem, though I don't know why )
I get that there can be conflicts, but it's surprising that I didn't need to set that to false when using my hacky version of
@metametadata: ah ok, i thought the view model is one derived atoms and you'd have multiple of them
@metametadata: how does it work if you don't use one of the reactions in the view model map? Are they computed anyways?
@martinklepsch: Yeah, here's a VM from TodoMVC example: https://github.com/metametadata/carry/blob/master/examples/todomvc/src/app/view_model.cljs Reaction is not recalculated if noone is watching it. But I've also read that creating a reaction and never using it can be considered an error because it causes a memory leak.
Here's a reply to re-frame issue explaining why not using reaction/subscription is a leak: https://github.com/Day8/re-frame/issues/29#issuecomment-81132123
@metametadata: @kauko here are the docs I said I would write: https://gist.github.com/martinklepsch/c5a2feacc63ce08565fcffe37951ab64 — hope this makes sense in the context of what we talked about earlier. In comparison to Reagent's Reactions this feels a bit simpler and more explicit to me but I'm also not overly familiar with the reaction impl.
The intro/usage is nice and easy to understand. It looks similar to reactions but is implemented using data-centric approach instead of macros. Kinda.
Cons: Rum-related stuff is not demonstrated and
subman name is odd, also I don't quite get what's going on in
(comment ..) blocks 🙂