There exists a 'binding' from your 'db' to your components that encompasses the whole thing.

@amashi: we’re working on docs but quite honestly don’t have the time for a longer explanation right now. the talks are the best source of info, right now that’s the only place we have the overarching info

OK, I will watch them. Thanks.

@amashi: to simply put my understanding of what Om Next buys you: You shift the control of the system to your clients. They bind to the “cloud” (whatever that means in your system — either a monolithic server or a group of microservices, or a combination of both) in a way that lets clients: 1. request the precise total response they need in their UI (without needing to reshape it in the client as you’d otherwise need, and without the burden of receiving too much or too little attributes in the server response) 2. atomically commit trees of data to the server (which are things you can easily do with things like Firebase, Meteor.JS, etc. but terribly hard to do with a RESTful backend) without actually having to sacrifice your precious relational database on the server (major improvement over Firebase et. al that I mentioned)

Does anyone have any job scheduler recommendations? I’m thinking of http://clojurequartz.info/ but wondering if anyone has any better ideas? We need to run things at various times and persist the schedule in a database.

that said, it’s not meant for every use case and for every application. But definitely a huge improvement over existing stuff if you’re building an application with such requirements

@brianosaurus: another option might be http://docs.caudate.me/hara/hara-io-scheduler.html

(disclaimer: i haven’t used it yet, but I’ve been looking for a scheduler myself)

adambros: thanks. I didn’t see it mentioned anywhere wether or not it persists the schedule to a db. Does it?

it seems to be more abstract, in that you define a handler and install it on a schedule

oh i see i misunderstood

let me take a look

from what i can tell it just uses a var hara.io.sheduler/*defaults*, so no?

Well, thanks regardless @adambros

@anmonteiro: I think I am failing to understand some things here (almost certainly because of my own deficiencies.) Most systems I've built do not allow clients to alter data, wherever it lives, without at least a bit of central validation. Am I misunderstanding you?

well you can obviously validate stuff on the server

what I meant is the ability that clients have to communicate the creation / updates of such data

that is much more evolved from the way we’re used to today

How so?

I really do think I am failing to understand something here.

what are you not understanding?

I can give you an example

But let's say I write an app that hits some endpoint and in some ways makes it update a datastore.

How is that different?

in that scenario, would you be e.g. able to create non-trivial temporary data on the client, communicate it to the server, and have it send you just the mappings from the temporary ids to the real, persisted IDs?

Om Next makes this scenario really simple

OK, so the advantage here is mainly about synchronization?

I do believe so, yes

this is why I mentioned things like meteor and firebase

That's a story I am very willing to buy, if so...

You have no idea how much code I have written to keep things in sync manually in the last year or so.

Between mobile apps, remote dbs, etc.

I’m certain that’s something you’re looking for, as per your comment regarding optimistic updates and rollbacks

that’s another selling point for Om

this is an optimistic update on the client: https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/cljs/todomvc/parser.cljs#L64

2 lines of code

right- well for instance in a recent app I wrote all my updates have to be optimistic, but...

Is the point here simply that the app-state can be rolled back to what it was before the update if it fails?

Or am I missing something really important?

To anyone interested: I just finished the first recipe on the cookbook. I'm not planning on making them pretty myself...so anyone interested in adding a bit of CSS love is welcome to do so. The recipe (tabbed-interface) includes some tidbits that will had wide interest: - How to leverage a union query to switch in/out different bits of UI at the same place - How to lazy-load data (in Untangled) during a mutation that is doing something else entirely (e.g. switch tabs also triggers a server load) https://github.com/untangled-web/untangled-cookbook/tree/master/recipes/tabbed-interface

This uses 0.4.7-SNAPSHOT, which I've put on clojars. WARNING: It requires om-alpha32 (there were renames from 31->32)

if you don't mess with the project file, it should be fine

I've been wondering about the "pass mutation to children" thing

in this case, doing the mutations in the children but putting :current-tab in a follow-on read wouldn't work?

Did you read the example already?

The client muattion has to change the ident...there is no problem with that...optimistic update (to switch to the tab immediately) is fine. From within that mutation (or as an additional mutation done at the transact level), one can trigger a load in the mutation code. You want this because the UI should not go examining global state...you want an abstract mutation to do the work if it is coming from the UI. Actually, I guess I could make the sample clearer now that you mention it.

I separated them into two mutations when in fact they could be combined, which is the point. However, I want them separate in the example so you can see the simplicity of the tab change (one line)...I need to add a comment that the load triggering could easily be combined with the change tab mutation, which is part of the point

You don't want to use load-data directly in the UI because some analysis of "what to load" needs to be done as you enter the tab...and the answer might be "nothing"

notes added to repo

@tomjack: let me know if it needs more clarity

Server-side security recipe created with README (HAS NO code yet...but describes a way to do it)

I'm just talking about the comment here https://github.com/untangled-web/untangled-cookbook/blob/master/recipes/tabbed-interface/src/client/app/ui.cljs#L63

(it seems to work. I was just wondering if there's something I'm missing about the "pass transact! callbacks down to children" thing)

the server-side security stuff is interesting

[*] is kind of puzzling

oh...passing callbacks. Have you not seen that in Om?

I've seen/heard it, I just don't know if I understand the reasons to do it

Ah, ok

Basic rule of list/collection management (and I would consider sub-tabs a collection of things):

1. Transactions that affect the collection should be done in the parent (owner that renders them)

2. If something in the UI of a child needs to trigger the transaction, then you pass it in as a callback (so you're still closing over the parent this in the transact)

simple as that

you use om/computed to pass callbacks because that causes the callback to be recorded "out of band" from the query result. This is needed because the sub-component can be re-rendered without re-rendering the parent...but it only gets the updated database query (which would lose the callbacks)

Way back in like om-alpha12 you just passed the callbacks in the property map (e.g. via assoc)...then we discoverd that problem

but.. if I simply do the transaction in the child, and use an appropriate follow-on read in the tx, then I can ignore the rule with no bad effect?

good question

I know that David N. made up this rule, and it was hard to get clarification of why exactly. If I had to guess (which should be pretty good): If you do the follow-on read I think you might get a double-render (re-render the child, then re-render the parent from the follow-on, which will again re-render the child)

not sure that matters in 99% of the cases

follow-on reads are really about updating things "elsewhere", so in concept you're right, but I think elsewhere is intended to be other branches of the tree, not the immediate parent. But my strong suspicion is that it is just a rendering optimization rule

Also, in principle, I guess it is best to not make children have to know about things that you really don't need to know about. The callback method makes it possible to make a subcomponent that can be used in any parent

oh, right, the current tab/navbar situation is different..

the follow-on read couples the two together

thanks, I'll try not following the rule and keep an eye out for stuff like that

sure...now that we've talked about it, I think the component isolation is a better reason

ah, right, was wondering if there was any 'good practice' about it

follow-on read couples you to a specific UI structure (loosly). Callbacks don't

I take that back

follow-on reads are about abstraction...this mutation causes this other dependent data to change. You should not care if that is a parent...or even know

[(add-friend) :friend-count]

you know that adding a friend affects the friend count, but you should not care where that is rendered. Completely decoupled fro m UI...coupled only to the abstraction

[(add-item-to-list) :parent-prop]

couples the mutation to the idea it is embedded in a child that has a parent

But I cannot think of a technical reason why the latter would fail to work

ok...long day. Headed to bed. Thanks for looking at the cookbook

thanks for making it!

Another thought for the cookbook - query caching, along the lines of the om example would be great to see - I can see us serving a lot of cacheable stuff from our queries: https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial

Add it to the wiki

Done, just throwing out here in case other people want to pile on or bring up good info I might not have seen. 😄

Hi untanglers! Are there uses cases for a CMS / static site generator using untangled? Would you use untangled to create a CMS that a non-tech client can control?

I'd like to try datomic for a new projet and it seems the integration untangled + datascript + datomic is very natural

Not sure though if a CMS/blog app could be a good fit...

personally ive been wanting to make a CMS with it, but I’m not sure I understand your question. What are you looking for in untangled to help you make a CMS?

We're actually building a template/HTML component in house (prob won't be open source though)...@adambros worked on it

We're not directly supporting DataScript on the client, though you can hook it in.

I'm recommending you keep the UI database to the Om default format. If you also want a Datascript db on the client, then you'd have the two interact/coordinate. Rendering directly from DataScript seems like a good idea on the surface, but in practice not good (performance, schema, etc)

you'd typically want your datascript to mirror your Datomic...and if you study Untangled at all (or Om) you'll see that it is rare for your UI structure to match your schema graph.

so, you have to do a transform anyhow, which is the Om parser...but in Untangled, we eschew that for a more direct data manipulation approach

@tony.kay @adambros So I guess I should forget about datascript for now. So the db will be available on the server side (datomic). It will provide the content to Om/Untangled-client that will load it up front to constitute the state? I guess I would need an example of a datomic connected to untangled (without datascript) Are there any?

(As you can see, I am not a senior developer, forgive me for that!)

a ton

well, a decent amount

Please see the resources on the website, and on github. TodoMVC, Tutorial, Cookbook (new, but has a few things in it)

Ah, specifically connected to datomic: we're persisting todomvc in datomic, I think

in-memory, but all you change is a URL

The tutorial does describe a lot of it

Will start there I guess. Thanks a lot!

sure, there is a lot to document still...so be prepared to dig a little. Trying to remedy that as quickly as possible

If I find an opportunity to help in the doc, I will. But can't promise 😉

I need to stay humble first 😉

appreciate anything you feel like helping with. As a beginner, start simple...don't try to do it all at once

@tony.kay I just finished an initial implementation of a client side router focused on om next, see #C06DT2YSY or https://github.com/IwanKaramazow/om-router If I need to provide some specific hooks for Untangled, let me know. The plan is to evolve this thing in something useful...

New version of the Clj West talk up: https://youtu.be/TU9hWTZcKy0

tabs state is already normalized. So to get the whole of the state all together need to use some tree->db. And this seems to do the job okay:

(def merged-state (atom (merge state/already-normalized-tabs-state (om/tree->db ui/non-union-part-of-root-query state/initial-state true))))
(pprint @merged-state)

I'm randomly getting a bunch of warnings like WARNING: Use of undeclared Var om.util/join-key in untangled/client/impl/data_fetch.cljs

on master, this code was working fine a few days ago

I've got the same version of om "1.0.0-alpha31" as the untangled repo.

@currentoor: you’ll need alpha32 starting with 0.4.7-SNAPSHOT

@ethangracer: thanks

The difficult to debug error is from the same line that gives this compiler warning:

WARNING: Use of undeclared Var om.util/ident? at line 27 resources/public/js/compiled/dev/untangled/client/impl/om_plumbing.cljs

.. think I'll try alpha32 as well...

Yes that fixed it - SNAPSHOTs can change beneath your feet!