om

Please ask the channel first, not @dnolen directly!
tony.kay 2017-08-23T02:07:18.000149Z

@alpox I’ve just pushed my first snapshot of https://github.com/fulcrologic/fulcro-sql. It will work with Fulcro or stock Om Next. At the moment everything except the graph query against SQL is working (migrations, test support, seeding, web-server component). I just started the library today, so that is probably a decent number of documented and tested features for 8 hours of work. In the coming days I’ll be expanding it to support running standard Om/Datomic pull queries against an SQL database, assuming the schema is relatively sane 🙂

tony.kay 2017-08-23T02:10:23.000087Z

@wilkerlucio @alpox On Datomic: I’ve seen people actually save money with Datomic in the cloud. It caches things so aggressively that they never get out of the free tier on I/O.

tony.kay 2017-08-23T02:11:46.000048Z

So, the capital expense is deferred (for as long as you don’t mind updates), and the ongoing costs are reduced. There are still reasons to use other databases, of course, but cost of Datomic would not be my primary reason.

2017-08-23T02:57:36.000041Z

just wrote my first full-stack om.next app with SQL and bidi/yada! it took me 3 days to learn and write everything i needed for this, but it was worth it

2017-08-23T02:57:57.000147Z

it's also just an app with a list synchronized to a database, but yeah, start small

alpox 2017-08-23T09:34:36.000132Z

@tony.kay Thanks for the work! It looks promising. I will take a look at it 🙂 Short sidequestion: What is the relation of untangled and fulcro? They seem to be in the same spot. But i didn't hear of fulcro yet

2017-08-23T09:36:21.000457Z

@alpox The untangled name is owned by the company @tony.kay used to work for. He knew they wouldn't maintain it but couldn't keep the same name, so forked it. To all intensive purposes, they are the same, but future development will be going into fulcro.

alpox 2017-08-23T09:38:17.000408Z

@danielstockton Ah, thanks for the clarification 🙂 great to see that its going on

sundarj 2017-08-23T09:39:54.000153Z

@alpox there is an #fulcro, just fyi

linuss 2017-08-23T10:58:26.000321Z

Hey guys, I'm trying to change a query parameter of a component that's not the root component from a mutate method, which is triggered from yet another component. I can't seem to find a way to get the component as an argument to the set-query! method.

linuss 2017-08-23T10:59:01.000108Z

All I've found is the app-root reconciler method, which returns the root component

2017-08-23T11:13:57.000115Z

@linuss You could pass it down the tree as a computed prop.

linuss 2017-08-23T11:14:46.000269Z

Well, the component that triggers the mutation is a sibling of the component which query I'm trying to change

linuss 2017-08-23T11:16:34.000214Z

Let me rephrase the question, I might be going about this completely wrong. I'm writing a front-end which gets some remote data from a back-end. However, to retrieve this data it needs an authentication token. I've tried simply retrieving the token and storing it in the global state, but that won't trigger rereads of other queries that depend on this token. To solve this, I've used the token as a query parameter

2017-08-23T11:17:05.000234Z

Tbh I avoid set-query! completely and this doesn't sound like a good use-case for it. If siblings are needing to make changes to each other, it seems like something you want to keep on app-state.

2017-08-23T11:19:21.000166Z

Oh right, ok. I can tell you how I handle this. I store the token in state {:user {:token asdnfdidhfabd}} and then in my send function I do:

state                   @(om/app-state (om/get-reconciler wrapper))
        token                   (-> state :user :token)

linuss 2017-08-23T11:20:06.000033Z

ah!

linuss 2017-08-23T11:20:07.000361Z

okay

2017-08-23T11:20:34.000120Z

wrapper is the root component, which I pass to some go loops that i initialize in my wrapper componentDidMount

linuss 2017-08-23T11:22:53.000042Z

I'll give that a try, thanks!

2017-08-23T11:23:52.000161Z

I also check for :user returned from the backend in my merge function and save it to localStorage. This way, I can keep them logged in on refresh and keep refreshing my token periodically.

2017-08-23T11:24:31.000178Z

When I set up my initial app-state, I check localStorage to see if we can pre-load the user data.

linuss 2017-08-23T11:26:03.000085Z

Yeah, I've done something similar before

linuss 2017-08-23T11:26:46.000306Z

But, how do I re-trigger a read that's unrelated to the token read, but that does depend on the token?

linuss 2017-08-23T11:27:16.000179Z

I know you can return {:values {:keys [...]}} from a mutate function, but it doesn't seem to be used

2017-08-23T11:29:36.000279Z

I'm triggering a route change which fires off my route queries again.

2017-08-23T11:29:47.000052Z

i.e. from login -> next page or home page

2017-08-23T11:29:59.000261Z

route/root

linuss 2017-08-23T11:33:23.000396Z

Yeah, I do that too, and that works, but it won't retry to read the remote data

2017-08-23T11:36:14.000409Z

Actually, I have my route change inside a (js/setTimeout (fn [] (change-route!)) 0)

2017-08-23T11:37:02.000025Z

I believe I had similar issues before, this delays it to after the next requestAnimationFrame

roklenarcic 2017-08-23T16:51:39.000569Z

I have hard time reconciling (heh) having static queries per component and reusing components

roklenarcic 2017-08-23T16:52:19.000337Z

like if I have 3 listboxes, which present same structured data, but each of these presents a differently filtered list

roklenarcic 2017-08-23T16:52:44.000194Z

I would like to reuse the component, but query is static

tony.kay 2017-08-23T17:04:07.000333Z

@roklenarcic You have a number of options. If the query needs to change but the know variations are constant, then 1. unions are a probable answer. If it is something like a dynamic schema that users can expand, then 2. Dynamic queries let you change the query at runtime. The third option is to not use a query, and just pass in props calculated from the parent that queries for generic (non-normalized) opaque-to-the-other-components data.

tony.kay 2017-08-23T17:05:28.000375Z

You can also separate the “functionality data” from the “display data”. In other words, have your functinality (e.g. folding) in one component and display in another, and make them query siblings, but nest the UI.

tony.kay 2017-08-23T17:08:51.000419Z

The section on bootstrap modals in this documentation shows the last technique: https://fulcrologic.github.io/fulcro/guide.html#!/fulcro_devguide.N15_Twitter_Bootstrap_Components

tony.kay 2017-08-23T17:09:48.000517Z

The modal has a query, as does it’s content. React composition (children) are used to compose the UI. The examples assume Fulcro, but the concepts are identical for stock Om Next.

roklenarcic 2017-08-23T17:48:53.000473Z

compassus and reloads and queries don't play nice with each other

roklenarcic 2017-08-23T17:50:19.000763Z

when I change queries, the page reloads, but console log tells me queries were done using the old queries

roklenarcic 2017-08-23T17:50:38.000112Z

things outside the compasus route system update just fine

roklenarcic 2017-08-23T18:59:46.000467Z

hm I guess queries get cached when using defonce and an app

roklenarcic 2017-08-23T19:00:46.000831Z

When using a list of items, should I keep info which item is selected in the list in app state atom or in om/set-state! react state?

matthavener 2017-08-23T19:01:54.000156Z

probably om/set-state! which is react component state

roklenarcic 2017-08-23T19:52:19.000143Z

but that selection will get cleared whenever the component is rerendered

matthavener 2017-08-23T19:54:42.000078Z

not rerendered, only if its unmounted and then remounted later

matthavener 2017-08-23T19:55:01.000420Z

but you’re right, it can get cleared in some circumstances, so you have to know when its safe

roklenarcic 2017-08-23T19:57:04.000470Z

hm, you're probably right