Fork me on GitHub
#om
<
2017-08-23
>
tony.kay02:08:18

@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.kay02:08:23

@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.kay02:08:46

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.

cjhowe02:08:36

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

cjhowe02:08:57

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

alpox09:08:36

@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

danielstockton09:08:21

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

alpox09:08:17

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

sundarj09:08:54

@alpox there is an #fulcro, just fyi

linuss10:08:26

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.

linuss10:08:01

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

danielstockton11:08:57

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

linuss11:08:46

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

linuss11:08:34

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

danielstockton11:08:05

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.

danielstockton11:08:21

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)

danielstockton11:08:34

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

linuss11:08:53

I'll give that a try, thanks!

danielstockton11:08:52

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.

danielstockton11:08:31

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

linuss11:08:03

Yeah, I've done something similar before

linuss11:08:46

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

linuss11:08:16

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

danielstockton11:08:36

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

danielstockton11:08:47

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

linuss11:08:23

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

danielstockton11:08:14

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

danielstockton11:08:02

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

roklenarcic16:08:39

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

roklenarcic16:08:19

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

roklenarcic16:08:44

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

tony.kay17:08:07

@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.kay17:08:28

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.kay17:08:51

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.kay17:08:48

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.

roklenarcic17:08:53

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

roklenarcic17:08:19

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

roklenarcic17:08:38

things outside the compasus route system update just fine

roklenarcic18:08:46

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

roklenarcic19:08:46

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?

matthavener19:08:54

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

roklenarcic19:08:19

but that selection will get cleared whenever the component is rerendered

matthavener19:08:42

not rerendered, only if its unmounted and then remounted later

matthavener19:08:01

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

roklenarcic19:08:04

hm, you're probably right