Clojurians Log v2

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.

but (debugger-added?) doesn't need anything else from the namespace

Wouldn't you also need debugger/connect required?

ohh

you're right

crap 🙂

OK )

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

that's not too bad

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

❤️

I'll have to see how to make the :on-start signals work with Rum

and maybe add a section to the guide about Rum

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

@martinklepsch: cool, I didn't know about this feature

This might be helpful to understand the possibilities/getting started: https://www.martinklepsch.org/posts/parameterizing-clojurescript-builds.html

offtopic: do you have an RSS feed for the blog?

@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

@metametadata: unfortunately not right now

@martinklepsch: ok, just wanted to subscribe 🙂

@martinklepsch: I just pretty much copied the reagent-carry module

https://github.com/Kauko/predictor/blob/master/src/cljc/predictor/carry_rum.cljc

@kauko: ah ok, so you don't have many view-models yet

uhm

Well, yeah I guess, I've hardly started on the project

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 get! and 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.

without a view-model, each component would just get the whole model

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

that probably depends on how high in the component tree you are

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

I will write some docs later today

Hmm, I'm trying to use the carry-atom-sync with devcards, but the data inspection / history stops working after one interaction

just in case - make sure you use v0.2.0

I am

and it seems to work fine in my application

@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

makes sense

I really can't get the atom-sync thing to work with devcards o.O

it works fine if I use a hacky version of carry/app that takes the model-atom as a parameter

the atom sync also works fine in my normal app

but with devcards the card's data is updated once, but then stops updating

do you use defcard?

I guess I had some similar problem until I switched to defcard-rg

yeah, I think that's the problem - I can reproduce your issue when after switching to defcard

adding :watch-atom false option seems to fix the problem, though I don't know why )

huh, that works

:watch-atom true ;; whether to watch the atom and render on change

interesting

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 carry/app

yeah, hard to tell without digging into devcards code

hm

well, anyway, works nicely now 🙂

@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

Ah I see reagents reactions do have some extras for efficiency :)

@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 🙂

Maybe the lib may also benefit by providing a comparison example: lib's build vs. using raw derived-atom calls in and putting them into a map.