I’m not arguing against the power parsers give you, merely that it should be an advanced feature

Looking forward to that talk then @anmonteiro

also I’m pretty sure you’re still writing parsers even with Untangled?

I mean, you do have to write your mutations, don’t you?

yes, but reads on the client are handled for you

and if all goes well in the next few weeks/months we’ll have something similar on the server for reads & mutations

i guess i dont think of mutations as “parsing"

TBH I feel like parser was a misleading choice of wording

@adambros what do you mean by “write your own parser to get a web application going”? are you referring to server or client side?

and I’m quite certain that changing it to something else would attract a lot more users

just that in stock om.next you have to write your own read methods

@adambros hm ok… what’s the alternative in other frameworks?

or approaches?

you hard-code your reads inside the UI/views? 🙂

well in untangled (which just sits on top of om.next) it standardizes the db format so reads are just db->tree

i havent really had to think about reads on the client thanks to that

i do like the amount of power/flexibility om.next gives you, i however think that to reach wider audiences (if we even want that) we can’t overwhelm new users when their main concern is their next web app, not creating parsers

@adambros I’ve seen untangled but don’t know details about it

I agree, in many cases it’s a trade-off between power and how easy it is to get started, that’s the case with many tools, including outside software development imo

exactly, i’m just suggesting we make sure we have all the tools at our disposal

idk what you are looking to learn about untangled, but http://untangled-web.github.io/untangled/index.html and #untangled are good places to start

yes, I’ve seen their docs look nice but haven’t seen anything specific at first sight that offers a big win over plain om.next (I’ve been using om.next for about ~9 months now)

@adambros I know you mentioned db->tree - that’s actually something I’m yet to use with om.next, I’ve also barely scratched the surface of idents for various reasons

Just want to share my new hobby project http://ethereanmind.com here- It's an ethereum blockchain smart contract dapp, but the UI is 100% Clojurescript, OmNext, blueprint-cljs, and core.async. I also wrote a special OmNext parser variant that supports go blocks for the :value in parser functions, useful for handling the asynchronous data queries that have to be processed on the client against the blockchain- Here's the repo: https://github.com/drcode/ethereanmind

@drcode why you still include figwheel in the javascript?

oh and you have unbalanced <div> tag in the home page

@mavbozo my advanced compilation pipeline is broken for now, I'm going to get to that before the project goes out of beta... huh, how'd that </div> get there? thanks for the pointer

@anmonteiro Question about parameterized queries. When I set filters, compassus puts the params in the state atom. How can I get these to the component when the query is made? Our current way of doing this feels a bit hacky to me.

@creese hrm.. I never really envisioned params that are in the state atom to be used in parameterized queries

Having params in the URL allows you to cut and paste it to another user.

We may be misunderstanding each other

do you mean parameterized Om Next queries or parameterized browser URLs?

The query params in the URL are used in a parameterized Om Next query when rendering the component.

I think might be a tangential issue.

If I have two components on a page, say a table and a filter, and I want the filter selection to affect the data displayed in the table, what is best practice for that?

creese: my two cents: filter mutates local state, and the parser function for the data reads that local state along with the table state to determine what to return

That's what we're doing.

I'm wondering if we should be using IQueryParams though

,.Hey I have a design question. Say one is to implement a comment system (where users can submit a comment via textarea and have it show up on the screen) ... When you start doing nested comments (comments to comments), what's the best way to represent that in om components?

probably give each comment a unique id nd let om's [kw id] resolver handle it

@creese IQueryParams is actually not that a good fit for dynamic stuff

you may be better off with just local or global state

that has been my experience

@sova looks like a perfect use case for recursive queries

Is that a limitation of the library? Seems like static params would not be very useful.

also a limitation of the library, but mostly a number of gotchas that only advanced users will know to identify

@anmonteiro thanks 4 confirmation

I think all the comments can live in one place in the app-state-atom

and I think the keys can indicate the "parent element" , as well as every comment having a ref to the root element (basically the page that the comments are on)...

so for a recursive om.next query, if the set is empty it'll just not render, but while there are recursive elements it'll keep rendering?

(new territory to me but i'm stoked, the power of lisp gently shines through the clouds...)

@sova don’t have time right now to explain all the nitty gritty stuff of recursive queries, but try to look over here https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/core.cljs#L243

@anmonteiro thanks man, I'll take a look. the great part is is that it'll probably be just a couple lines, now the study behind getting them right xD

@anmonteiro do you recommend my data tree look nested as it is in the example? i was thinking of just having a "pile of leaves" and inspecting it iteratively

@sova your data will be flat after normalization

aha. okay, so I can provide it flat in the first place

as long as it’s in the default Om Next database format