Clojurians Log v2

I support the idea of namespaced events. I usually partition my app by views/usage with an additional general “components” folder for generic components. I think the challenge is to make a trade off between generic events and reasonability/locality of your logic. Moreover, you need the discipline to avoid calling events from other views, except the general one.

@genekim might be interesting to render that out in a form that can be consumed by the Graphia application

Anyone using Klang? I am trying to work out why it's not loading. The ensure-klang-init function is complaining "Klang: Can't find React. Load by yourself beforehand." but I'm not even clear how that function is getting invoked. I can see preloads for 10x, re-frisk and so on but I've not added anything for Klang specifically.

The related stack trace isn't helping me very much: https://gist.githubusercontent.com/mmower/e371952fce3be21778267daabf564fc7/raw/7e04f3bf51cb1e576b83fad7b0910b14f68bd6d2/gistfile1.txt

Ah, I think the Klang info! macro is invoking this the first time you use it.

So, why can't it find React

It's testing for exists? js/React I wonder if that is an outdated method. Klang hasn't been updated in a few years. Is there something else doing the same thing baked into re-frame now?

@neo2551, sorry just reading over this. I've been wanting to do something similar for a while, how are you experiments coming?

It works, really well.

What I created several datascript/db inside my app-db, and the subscription works swiftly.

I usually try to have the datascript part in a single sub, and then pipe it into other subs for refinements, but I am really happy with the result. It alleviates me from deciding about a structure inside the app-db, at the cost of defining a schema for the ds and have a few transformation for transacting the entities.

You use d/db-with for performing transactions, and the rest is typical re-frame. In contrast to re-posh, the way you write the subscription feels more “natural” and you still get access to all the cool stuff from datascript such as access to the indices and all.

Do you have any example code other than what you've got prior to the thread?

Nope, but it summaries exactly what I did. Put a (d/empty-db) somewhere on your app-state and start to query and transact with it.

Immutability rules.

I'll give it a go, do you mind if I msg you here if I have an issue?

No problem :) Also message me if it works!

@neo2551 This sounds super interesting, as well — so to make sure I’m processing this all correctly: Option 1: @rberger suggests breaking up the events namespace, which I’m guessing are all required into the main events.cljs. This has the benefit of organizing the events, modularizing, information hiding, etc. Option2 : @neo2551 suggests going beyond just splitting up the events namespace, but actually creating separate dbs/events/subs, as per: http://day8.github.io/re-frame/App-Structure/ I think in my case, I’m going to try Option 1, because I’m not quite ready to distangle everything yet — but making separate piles of events is something I can manage. 🙂 thank you, all!

@mikethompson Thank you for re-frame — it is so fun to build things with it!

The advantage of having fully qualified namespace is also to know where they are defined. But good luck :)

@genekim We don’t require the events/*even.cljs in the top level / global events.cljs. We just require them as needed in the usually parallel views/*view.cljs files. Our current project did evolve from a global events.cljs to this model and I susepct we may eventually evolve to something like what @neo2551 suggests. But evolution is good. Learn as you go. One thing good about having them all in a global events though, is no worry about circular dependencies. It hasn’t bit us hard, but it has bit us a few times. Usually a bit of refactoring/rethinking fixes that.