This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-28
Channels
- # admin-announcements (1)
- # aws (2)
- # beginners (21)
- # boot (28)
- # braid-chat (1)
- # cider (51)
- # cljs-edn (7)
- # cljsjs (35)
- # cljsrn (2)
- # clojure (85)
- # clojure-chicago (7)
- # clojure-czech (1)
- # clojure-gamedev (3)
- # clojure-poland (2)
- # clojure-russia (80)
- # clojure-sanfrancisco (1)
- # clojure-uk (5)
- # clojurebridge (9)
- # clojurescript (68)
- # cursive (29)
- # datomic (23)
- # emacs (2)
- # hoplon (94)
- # jobs-discuss (15)
- # juxt (2)
- # liberator (2)
- # luminus (16)
- # mount (12)
- # off-topic (7)
- # om (57)
- # onyx (58)
- # proton (10)
- # re-frame (9)
- # reagent (38)
- # remote-jobs (2)
- # rum (12)
- # untangled (136)
@currentoor: Yeah, @davewo and I worked on a sente-based entity subscription system as a tech spike. We don’t need it yet, so could not spend time refining it for production use yet, but agreed: Datomic tx monitor makes it relatively easy to subscribe not only to an entity, but an entire graph query.
@tony.kay: a lot of exciting stuff happening over here 😄
curious if you tried something for unsubscription? I am interested to see any implementation of that
I already asked this question over at #C0620C0C8 and at the posh gitter channel, but I figured might as well ask here too.. I've always thought DataScript looks really interesting, and I thought about starting a small demo project today with Reagent+Posh. But then I realised, I don't know what exactly is the difference of Om Next and Reagent+Posh. If I'm doing the work of wiring up Posh+DataScript to my Reagent application to get colocated data queries and whatnot, why wouldn't I just use Om Next?
Am I not just recreating Om Next if I use Posh? Won't I run into problems that Om Next has already solved for me?
The reason I'm asking here and not over at #C06DT2YSY, is that there were a couple of people waiting for answers to their own questions and I didn't want to bury them Besides, I'd probably try to go with untangled and not just pure om, since untangled probably solves some problems I'd run into with just om
One thing to keep in mind is that Untangled currently works with default database format rather than DataScript.
I don't actually know what would be the advantage of using DataScript with Om rather than the default database format either.
You read my mind just then - about 'what is the point of Datascript?' Datascript's disadvantage is that it is slower.
Posh is similar to reframe from what I understand?? The only disadvantage I can think of with Untangled would be the Om Next learning curve. Posh would I imagine be easier to get up and running quickly with.
Yeah, that's honestly kind of what I feel like too. I've been looking to get into Om Next, but honestly, it's really damn difficult to get into. But then when I started thinking about setting up a project with reagent+posh+datascript+datomic+whatnot, I realised I'll probably just end up learning/recreating all the concepts Om Next already has, you know?
and if Posh doesn't force me to think about a difficult concept that Om Next has, it probably means that I'm going to run into problems later
I’m very much interested in untangled, but with DataScript integration. My case is mainly client-side only, where I fetch lots of raw data that I need to parse into DS and make datalog queries on. I don’t want these queries to be done server-side. If I used the default om.next structure, I would need to re-invent DS for any non-obvious queries. I’m going to experiment with loading all my business data into DS on the side and use the default untangled state for keeping a materialized view of just the data I currently want to render.
Untangled does your reads for you (in Om Next you write them). And its reads assume default db format. So I don't see it being easy/possible to use DataScript with Untangled.
Uhm, so the advantage of using datascript with om would be that datascript is faster than the default format?
It would be slower, since there is a level of indirection. But it let’s you write queries you otherwise would not be able to write with the default format.
Sorry, this is a topic that's been bothering me for a long time. I guess I've never really understood what the advantage of datascript is.
Well, as far as I gather, all you get with Om/Next is db->tree and a basic parse function you can extend. If all you need to fetch are idents + pull api it should suffice.
@cjmurphy: @pithyless @kauko Datascript has definite use-cases, and you can totally use it with untangled: Use the default DB format for the UI...use datascript as a separate database. On post-mutations, you can totally populate things into datascript. This could be useful for example, if you want to use complex non-ui queries to compute things...then put them into the UI database. This gives you the speed of the default db format for fast rendering. The ideal schema for storage (e.g. datomic/datascript) will never match UI...which is the reason for the Om parser...but that is a mess of complexity itself.
OR perhaps you set up a web socket, subscriptions, and populate those into datascript. Then do your transform from a DS query -> UI database for rendering
This turns the need for a parser into simple data transforms, which are easier to reason about and code
@tony.kay: this is exactly what I was thinking of trying; DS for data, default DB for UI. Thanks for the feedback
@tony.kay: is the performance thing you mentioned related to the thing where Om has static queries, so you always only need one query to get all the data you need? I mean, does this only work with the "UI db"? Or is the default db just somehow inherently more performant than datascript?
@kauko: The default db format is several orders of magnitude faster than datascript. Datascript is a real database with indexes, etc. The default db format is just maps...which are very very fast
So, if you need real queries of complex nature, datascript may make sense...but for converting a UI query to UI tree....the plain map thing gets you good UI performance.
@kauko: On posh: The problem with co-located queries and datascript is that your datascript database is not going to match your UI structure...unless you structure it that way. Om has you make a parser, but that is kinda hard too. So, not only is there no server integration, you still have to solve the mis-match between your real data schema and your UI...and you have performance issues with running a real database to server a UI. So, while Datascript sounds like a good idea in theory, I think if you try to drive your UI with it you'll end up with big problems you can't easily solve as the app gets big
Hmm, not sure I understand. Doesn't Om next structure its data in a.. relational manner? It's not a tree like it was in Om?
I don't see how Om's database (if you can call it that) can match the UI structure, but datascript's can not
Then again I've never actually used either one. Perhaps this would be obvious if I had more experience
that is not the point. The point is that typically the reason for wanting DS is to do advanced queries and use datalog on real data....and that schema is almost certainly not going to match your UI
so...use a simple db (maps) for UI (which wants speed) and keep DS on the side to do the advaned stuff (which for example only updates on server pushes of subscribed server data in good schema form)
There's no point to use DS if all you want is a UI db...it's like putting a thumbtack in with a jackhammer
I see, I think I understand. Can you give me an example of an "advanced query"? At what point do you think would it be justifiable to bring in DS?
I imagine this is related to the limits of Om's pull syntax (I believe that's what it's called)?
[unrelated] so I've been looking at the Tabbed Interface recipe, and am wondering ... is that the same approach you'd follow for a (possibly-accordioned) menu bar?
@tony.kay: that's sort of what I was leaning towards, with swapping out the main ui section based on whatever the "view" selected is.
Thanks Tony for the comments, I've learned a lot. It feels like some sort of a comparison of Posh and Om could be pretty valuable to the community, although that could be difficult to write. I've been talking to some of the Posh folks over at gitter today too
It feels like the main thing keeping people away from Om is that Om looks pretty hard, and it feels like it requires quite a bit of code to get set up. Hopefully Untangled will help with this
This is one of the things that makes Reagent so popular: it's so damn easy to get going with it. Since Posh was initially built on top of Reagent, it's probably easier for peopel to adopt Posh rather than Om
@tony.kay: is that this page? https://github.com/omcljs/om/wiki/Queries-With-Unions
@curtosis: Yes @kauko: Only time will tell....I agree Om is too unapproachable for the masses. Hopefully Untangled helps.
@adambros: What do you think about removing log level setting in the db fixture? https://github.com/untangled-web/untangled-datomic/blob/968cb2232fa51a3e067c357c006de9278d134dd8/src/untangled/datomic/test_helpers.clj#L37
The reason I mention this is that it has a lexical side effect … things lexically scoped within the macro can’t log info unless they explicitly pass in a log level. Also, it’s a test so I’m not sure if only showing fatal is necessary? What do you think?
@brianosaurus: if you remove that you can end up with lots of logging around schema & db setup
i could be persuaded to instead of removing it, wrapping only the db-fixture
& the stop
in the with-level, but not the form
that’s a great choice.
do you need me to do it? otherwise a PR should be fine
I’ll add a PR. Once again, I’m in crunch mode until Monday…it might be a couple days unless I decide to do it tonight.
sounds good
Huh. I'm trying to run the untangled tutorial, I got the thing working once with the "all builds" profile, but now no matter what I do I get an empty page and in the console "Installing cljs-devtools: custom-formatters dirac sanity-hints"
Compiling "resources/public/js/tutorial.js" from ["src/tutorial" "src/shared"]... {:tag :cljs/analysis-error} ANALYSIS ERROR: No reader function for tag js in file file:/Users/teemukau/code/untangled-tutorial/src/tutorial/untangled_tutorial/I_Building_A_Server_Exercises.cljs on file null, line null, column null
not sure why, but I can tell you that that error is possibly the most annoying & useless error I’ve ever seen
i have however had success running lein clean
(and optionally git clean -xdf
)
but i have my doubts if you just cloned untangled-tutorial
and as a last resort wiping untangled & co. from your ~/.m2/repository/
i might ask that error to #C03S1L9DN, and maybe see if @tony.kay has anything
haha, what fixed it?
lein clean did it. Don't know why I didn't think of it at first, I use it all the time with weird problems like this
i might still ask #C03S1L9DN just because the no reader function for tag
is really annoying
as i said, a healthy dosage of lein clean
usually does the trick
So, just finished the design for full server-push integration. We should see something pop out in Untangled in the next week or so, and I'll finish a decent implementation of background-loading on top of that. I'm thinking I can get the effect of background (parallel) loading with plain send as well as a fallback, but the websocket implementation will be a lot better for the real use-case people want (e.g. long-running things where we don't want to worry about timeouts and inventing thread pools)
@kauko: which version of Clojurescript were you using?
if earlier than 1.8.34, that’s something that has been fixed
https://github.com/clojure/clojurescript/commit/68524a89eea8a8ae6cb69d1329acb3e3025c0fb6
has to do with the analysis compiler pass
thanks @anmonteiro, now if only i could replicate it and see if it fixes it once I upgrade
way to replicate is: - compile once
delete some analysis cache file
compile again
see if it breaks
In general, we should upgrade all of our deps to the latest and greatest cljs. Lots of bugs fixes happen all the time. Assuming our other deps are not broken as a result. I've been waiting for a time to test that out...anyone is welcome to play with it and let me know what combo of things works (figwheel, cljs, clojure, etc)
@adambros: truncating your cache.edn
file should allow you to repro
@tony.kay: re: deps, CLJS 1.8.51 was released the other day
Yeah, I just want to make sure everything works with it...e.g. lein cljsbuild, figwheel, etc
I'm looking into helping to get a deployable version of our untangled app packaged, and one of the challenges is providing a proper config.edn file - we prefer using 12 Factor style config in our deployment strategy, where we can change individual configs with environment flags. I'm considering the implications of replacing the config component with our own custom environ-powered config component. Seems like it should work, but are there any obvious issues with that I'm missing?
I don't know that redefining the config key to override the original config component will work as expected, I guess that's the first thing to verify.
Yeah, that definitely works - is it likely to break anything as long as we keep the new config component looking like the old one (map with all config stuffed in :value)?
so i wrote the config component under @tony.kay's direction but I can confirm your last question, that as long as its under [:config :value] in the system it will work however you implement it
i would be curious to know if you think if being able to reference system variables in your config, with something like :ENV/name would suffice?
That would likely suffice, yes.
(or a reader tag)
im not familiar with 12 factor style config, but you can easily have different config files per user & machine
We do mix in some things with a boot task, but I'm not sure if we use that really
eg: when you run the app with java -jar app.jar
you have to specify -Dconfig=/path/to/config.edn
you could dispatch that path based on some env var
eg: -Dconfig=$CONFIG_PATH
So 12 factor is a thing heroku came up with (I think), one of the things is basically using the shell environment for any configuration, to avoid having to have a different file per server in your build DB_URL=.... DB_MIGRATIONS=... java -jar app.jar
It makes it pretty easy to update configuration - you don't have to roll a new build or modify config files in place
I'm not sure how much of our decision to go that route is just based on habit from our other apps being hosted on Heroku though
@therabidbanana: Have a look at Aero https://github.com/juxt/aero, it’s a nice compromise between the 12factor style and storing things in a config file. It’s also extensible through edn readers.
{:favorite-color #env [FAVORITE_COLOR “blue”]}
reads to {:favorite-color “blue”}
only if the env-var FAVORITE_COLOR
is not set
There’s also support for Om.next style links through the ^:ref
tag, that takes a get-in
style vector of keys into the config.
aero looks nice, and as long as you can put the configuration in the system under [:config :value]
i see no reason why you couldn’t use it
or any other config library
Nice - thanks @gardnervickers - I'll take a look. Sounds like it could help.
Might be something that could be mixed into the untangled config component? Then people could optionally support env vars without the component needing to get much more complicated to implement?
personally i would be ok with aero, i would just want to see what @tony.kay thinks, as i have little experience with configuration & deployment
but as far as just allowing env vars, i can easily figure that out or someone can do a PR on this file: https://github.com/untangled-web/untangled-server/blob/f1fe7d88899107eaf0c57be34b2179a319ae765d/src/untangled/server/impl/components/config.clj