I've been seeing a lot of helpful information on that site. I'm glad it's linked on re-frame's readme.

Btw I found out what that " Warning: unmountComponentAtNode(): The node you're attempting to unmount was rendered by another copy of React." is from. It's caused by popping out re-frame-10x and then reloading the page. Since it's another window it doesn't get refreshed so it is in fact a different copy of React than the currently running copy. You have to close the window and refresh the page again for it to reload properly with it detached.

@mikethompson Would it be possible to add the ability to create a drawer with 10x so that you can just close the drawer to view the whole site (it covers up the right side of the site currently) and then open it again when needing to use it?

@madstap I have to say though that I don't agree with the author regarding this section: "Keeping Events and Subscriptions together Now I hope it's clear that Events and Subscriptions are tied together. They are coupled because they both need intimate knowledge of the structure of the Database. They both need to change when the Database changes. That's why I like to keep Events and Subscriptions that touch the same part of the Database together. For instance, all of the Events and Subscriptions dealing with the shopping cart could go near each other or at least in the same file. When I want to change where in the Database things are stored, I can see everything that needs to change within close proximity. This recommendation actually contradicts the structure given to you by the Re-frame Template. That template has separate namespaces for Events and Subscriptions. The template is wrong in that way. I would much rather have a shopping-cart namespace with Events and Subscriptions mixed together. I will put everything that touches something under the :cart key in that namespace. Those things will change together, so they belong together." I thought it was pretty clear in the re-frame documentation why they are separated.

Correct me if I'm wrong, but I'd also argue that this is not idiomatic re-frame. From my understanding you would just have the idiomatic sub above that and in your view function you would do a simple count on the sub.

Especially when in this example it only pertains to a specific component

I agree with him on this, I like to keep a namespace for the views of a component and one for the logic (events and subs). I don't think it matters that much though, the important part is to divide your app by component, which is then divided by views/events/subs or views/logic. The re-frame template is divided into views/events/subs at the top level, which in my experience is the wrong way to think about it.

It seems very trivial, but I'd still not do any calculations in the view

From my understanding, the purpose of separating them is to reinforce the domino explanation. They are also doing separate things. One is modifying data and the other is retrieving data. When you combine them together it hides that important explanation.

> I like to keep Events and Subscriptions that touch the same part of the Database together this is the only part that stands out as being very “place oriented”

one of the reasons that you create named subscriptions vs. querying the structure of the app-db is that it allows you to muck around with the shape of the app-db without changing the view

I'm pretty sure one of Rich's big talks discussed the general situation I'm referring to.

you might end up storing your db very differently than (semantically) you separate your app into components

it’s one of the problems you run into with Redux apps as well, where there’s this constant tension between trying to normalize your app state for perf and ease of transformation reasons but app UIs form a tree

I don't know if comparing to redux is a good idea here

I do see your point about keeping the view as dumb as possible, so in that light I will retract that it is not idiomatic, but I will still stand by the separation issue.

I don’t think it matters what file you put them in. lately I’ve been writing most of my apps as one big file and (maybe) splitting them up after the fact 😛

I do agree that complecting queries with commands is Probably Not a Good Idea(tm)

even just semantically

Well that's the thing. There are different ways of structuring your app that will still "work", but has the subtle effect of complecting how you reason about your app. Making it separate should establish very clearly in your mind how the application flows.

Yes that part seems very place oriented, and I do think that the division of the app into components should be done based on semantics of the events/handlers and not on how the app db is structured, but in practice events/handlers in a component usually works with roughly a "part" of the db.

@whoneedszzz it sounds like putting them in separate files is important to you, so you should do that. I don’t think it actually impacts that much. what I would fight against is what the author puts forward, where they suggest naming both the event and sub the same and trying to draw a dependency or some other sort of semantic connection between the two

I think you should revisit Rich's talks if you don't think it impacts that much

have you read the code he actually writes?

This is a prime example of the subtle things that seem innocent enough, but cause a lot of wasted time trying to debug an issue that was actually caused by you forgetting how the application should flow because you decided to combine them.

clojure.core is almost 8k lines long, for reference 😛

Just like how I was wasting time last night trying to work out a separate grid system for mobile when all I needed was to relook at how grids work

I’m being a bit snotty, but I haven’t seen or heard Rich talk at length about the size of modules, and I would probably disagree with him if he did.

I'm not following you on how the size of clojure.core has to do with what I'm saying

I'm not talking about the size at all

It's separating for reasoning about your application more fluidly. Nothing to do with file size

the size of how to organize my

How you reason about your code is crucial

Just the same as how acronyms have lost their meaning because you no longer think about what the word means. Ask a bunch of web developers what ReST actually stands for and be amazed.

you lost me there. I have no idea what that has to do what what we’re talking about 😛

I am in agreement that reasoning is quite important. and I do believe that separating your code into modules can be a tool to help readers understand the authors intent behind their code

I'm sorry. I do have a tendency to talk like we're in person on text and because of it being text communication it doesn't come across as intended.

it can also help in other ways, like reuse, code splitting, etc etc.

And I was getting a bit deep there without knowing my audience

It triggered some memories of conversations I've had with people about these sort of situations

Elements of Clojure actually I think had a nice little dialogue about the decision to split your code into namespaces and the type of effects it can have on a reader

@lilactown I'm looking to experiment with Apollo Client. From your point of view, does this repo of yours still represent good practice for using Apollo from Reagent? or have you moved on to better arrangements? Any gotchas? https://github.com/Lokeh/apollo-reagent (edited)

haha that did get lost in the scrollback didn't it

oh heh 😅 @mikethompson I would say that’s 50% of a solution

Though as a re-frame developer I'm curious of your thoughts on what we've been discussing.

we have something quite a bit more fleshed out at work but closed source atm

actually if you’re only interested in client side, the code in there is probably 95%

the biggest thing we worked on was doing SSR in Node.js + reagent

yeah, we're looking at using hasura server side

https://hasura.io/

nice

Okay, cool. So it sounds like that repo is a good starting point. Which is kinda what I'm looking for.

yep. 👍 it should be operational, at the least

And, the moment you get into these kinds of Apollo js libs, I assume using shadow-cljs is pretty essential ?

the mutate! function is pretty straight forward. I’m on PTO still but I’ll take a peak when I get back, I think there were one or two things w.r.t. creating and configuring the actual client and doing error handling

yeah, we use shadow-cljs. I haven’t bothered to try with figwheel

Any tips of query construction libs?

honestly, we just use strings

one thing I would do is rip out the conversion of the string to AST from the query functions

So you haven't found the need for https://github.com/Vincit/venia

nah

I'll have to go and have a further look at the repo to understand what you mean about "rip out the conversion of the string to AST from the query functions"

my grand plan is to at some point leverage some of the JS tooling there is for query validation and other fun things at compile time

@mikethompson That question was directed to you if that wasn't clear

observable-query (.watchQuery
                          client
                          (clj->js (-> {:query (gql query)}
                                       (merge config)
                                       (clj->js))))

@whoneedszzz sorry which question was that?

What your thoughts are about separating events and subs

Essentially did I get the understanding that was intended from the docs?

I'm not new to Sofware Engineering, but new to re-frame so just trying to make sure I understand correctly

The practice recommended tries to divide your app into logical units - which normally means "panels". So put everything related to one "unit" into a directory. That kind of division naturally tends to split things up along certain app-db lines, but not always. Instead, think to yourself, if I wanted to take this unit (panel) out of this app and put it into another app, then everything needed should be in this directory.

I split the events from subs ... ie I put them into different namespaces within that directory

But that's just so I know "instantly" when I look at a new code base where everything is.

So then I was correct about reasoning

Separating the panels makes sense to me and I got that from the docs when it talked about that

👍

Though to clarify, are you saying to separate distinct panels, such as say you have a login system and have separate views for a regular user versus an admin to separate those? Or as basic as a home page vs an about page?

home vs about

The site I'm working on currently is for my business and is just simply an informational site and the ability to make credit card payments via Stripe. It would seem kinda silly for me to separate those

normally

The about page is specific to this website so I would never be able to pull that out to another site

Everything except for the payment is static

The only state I have so far is to open and close the app bar drawer

@mikethompson Also forgot I had another question regarding 10x farther up. I pinged you in that message.

@mikethompson hello?