Fork me on GitHub
#om
<
2017-03-01
>
adambrosio00:03:10

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

adambrosio00:03:23

Looking forward to that talk then @anmonteiro

anmonteiro00:03:40

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

anmonteiro00:03:56

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

adambrosio00:03:19

yes, but reads on the client are handled for you

adambrosio00:03:48

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

adambrosio00:03:28

i guess i dont think of mutations as “parsing"

anmonteiro00:03:10

TBH I feel like parser was a misleading choice of wording

raspasov00:03:38

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

anmonteiro00:03:51

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

adambrosio00:03:24

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

raspasov00:03:48

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

raspasov00:03:53

or approaches?

raspasov00:03:24

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

adambrosio00:03:28

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

adambrosio00:03:42

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

adambrosio00:03:21

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

raspasov00:03:54

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

raspasov00:03:06

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

adambrosio00:03:32

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

adambrosio00:03:13

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

raspasov00:03:21

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)

raspasov00:03:46

@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

drcode13:03:22

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

danielneal14:03:18

drcode: This looks super interesting!

danielneal14:03:31

is this something that will always be "global" as in top 10 globally or could be run e.g. within an organization or topic

drcode14:03:10

in this incarnation it's just global.

danielneal14:03:28

I've always thought that this kind of thing would be great for github issues

danielneal14:03:39

I mean instead of github issues

danielneal14:03:44

the ability to add weight to something

danielneal14:03:17

you probably thought about this but you could maybe add a sort of meta thing for the etherean mind project itself to decide what features / bugs to work on

drcode14:03:25

yeah, the main problem right now is that ethereum isn't super scalable at the moment so tx fees are high, making it costly for that kind of thing. This related project is cool though: https://github.com/axic/mango

mavbozo13:03:55

@drcode why you still include figwheel in the javascript?

mavbozo13:03:55

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

drcode14:03:44

@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

creese16:03:25

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

anmonteiro16:03:17

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

creese17:03:22

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

anmonteiro17:03:11

We may be misunderstanding each other

anmonteiro17:03:24

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

creese17:03:12

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

creese17:03:28

I think might be a tangential issue.

creese17:03:40

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?

matthavener18:03:06

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

creese18:03:49

That's what we're doing.

creese18:03:02

I'm wondering if we should be using IQueryParams though

sova-soars-the-sora21:03:12

,.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?

qqq21:03:13

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

anmonteiro21:03:30

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

anmonteiro21:03:56

you may be better off with just local or global state

anmonteiro21:03:59

that has been my experience

anmonteiro21:03:21

@sova looks like a perfect use case for recursive queries

creese21:03:29

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

anmonteiro21:03:23

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

sova-soars-the-sora23:03:39

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

sova-soars-the-sora23:03:14

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

sova-soars-the-sora23:03:37

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?

sova-soars-the-sora23:03:57

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

anmonteiro23:03:41

@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

sova-soars-the-sora23:03:47

@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

sova-soars-the-sora23:03:03

@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

anmonteiro23:03:27

@sova your data will be flat after normalization

sova-soars-the-sora23:03:01

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

anmonteiro23:03:11

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