Fork me on GitHub
#carry
<
2016-07-01
>
kauko05:07:56

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

kauko05:07:23

but doesn't the closure compiler optimise imports in a way that only that function will be included, if it's all I use?

metametadata10:07:37

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

kauko10:07:18

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

metametadata10:07:40

Wouldn't you also need debugger/connect required?

kauko10:07:19

you're right

kauko10:07:21

crap 🙂

kauko10:07:26

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

kauko10:07:40

that's not too bad

metametadata10:07:11

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.

kauko12:07:20

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

kauko12:07:28

and maybe add a section to the guide about Rum

kauko12:07:51

the first time I read them I was confused whether Carry works with other view libraries besides Reagent (I asked about that on reddit)

metametadata12:07:28

:on-start/:on-stop signals are kinda orthogonal to Rum so you shouldn't have much trouble with them

metametadata12:07:20

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)

martinklepsch12:07:00

@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

metametadata12:07:10

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

martinklepsch12:07:11

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

metametadata12:07:37

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

martinklepsch13:07:36

@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

martinklepsch13:07:16

@metametadata: unfortunately not right now

metametadata13:07:13

@martinklepsch: ok, just wanted to subscribe 🙂

kauko13:07:55

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

martinklepsch13:07:25

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

kauko13:07:56

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

kauko13:07:13

but I guess I misunderstood your question, what does the number of view-models have to do with this? 🙂

martinklepsch14:07:54

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

martinklepsch14:07:40

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

kauko14:07:45

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.

kauko14:07:24

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

kauko14:07:23

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

kauko14:07:43

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

martinklepsch14:07:26

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

martinklepsch14:07:38

I will write some docs later today

kauko16:07:26

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

metametadata16:07:24

just in case - make sure you use v0.2.0

kauko16:07:46

and it seems to work fine in my application

metametadata16:07:38

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

metametadata16:07:04

Carry's view-model kind of corresponds not to a single re-frame's subscription, but to the set of subscriptions.

metametadata17:07:26

>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

kauko17:07:35

makes sense

kauko17:07:52

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

kauko17:07:13

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

kauko17:07:27

the atom sync also works fine in my normal app

kauko17:07:47

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

metametadata17:07:59

do you use defcard?

metametadata17:07:56

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

metametadata17:07:10

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

metametadata17:07:39

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

kauko17:07:24

huh, that works

kauko17:07:29

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

kauko17:07:49

interesting

kauko17:07:23

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

metametadata17:07:06

yeah, hard to tell without digging into devcards code

kauko17:07:22

well, anyway, works nicely now 🙂

martinklepsch18:07:03

@metametadata: ah ok, i thought the view model is one derived atoms and you'd have multiple of them

martinklepsch18:07:52

@metametadata: how does it work if you don't use one of the reactions in the view model map? Are they computed anyways?

metametadata18:07:52

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

metametadata19:07:04

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

martinklepsch19:07:15

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

martinklepsch22:07:33

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

metametadata23:07:35

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 🙂

metametadata23:07:10

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.