I want to ask your advice on the best way to monitor for changes introduced to the datomic DB that did not originate locally. presumably there would be a periodic polling of the DB but should the polling loop reside in the UI or what? Perhaps I can monitor the Datomic log and look for newness and if I find it, then perform some kind of refresh of the UI.

@fragamus Websockets + track what the UI is interested in on server + Datomic tx log + server websocket push of novelty

I'm pushing constant updates to the https://github.com/untangled-web/untangled-ui project. I'm trying to flesh out some examples for contributors. I'll try to keep the README up to date and informative about how to contribute. I'm making some devcards to demonstrate some possible plans of attack.

@therabidbanana I wrote the new defmutation, FYI...will release soon

defmutation with remote and action support is on clojars in 0.7.1-SNAPSHOT. See mutations-spec.

love to hear feedback and verification that it is right. Should make Cursive mutation navigation and docstrings work

as in the untangled-in-the-large video about components. Refactoring that source at some point too

ooops. see one thing to change

@tony.kay Checking out untangled-ui master, but getting this: Invalid :refer, var untangled.client.mutations/defmutation does not exist

^ correction, develop branch, not master

Is the released clojar up-to-date? I’m fetching untangled-client-0.7.1-20170210.055224-4.pom

hello guys

I’ve found in the untangled doc this sentence =>

Using InitialAppState
This is probably the easiest method to code, and the easiest to keep straight during development because the data is co-located with the queries and UI bits. The only disadvantage is that you cannot easily initialize parts of the graph that do not have a UI representation (which is probably rare).

I can’t understand why you can’t initialize parts of the graph that do not have UI

can someone explain it to me ?

@pithyless same problem here for untangled-ui

@baptiste-from-paris you can't initialize other parts because once you use InitialAppState it's going to take over the control of the initial app state, that will be built in a similar way that you root query is built, so, if there isn't a component telling to put some data there, you won't have other place to do it. makes sense?

oh ok

and what about the ui prefix tag ?

@baptiste-from-paris in InitialAppState it makes no difference, if you want to start some ui prefix there it's just going to work, the only place where ui prefix matters in when calling a remote, in those cases it will be elided, otherwise it works as any other keywords

ok ok thx

@pithyless @baptiste-from-paris looking at it...was working late, may have messed up 🙂

yes I figured this out when I checked your local time ^^

forgot to commit/push

snapshot updated

sorry bout that 😊

no problem

by the way, in your tuto you are giving an example with d3.js

https://github.com/untangled-web/untangled-client/blob/develop/spec/untangled/client/mutations_spec.cljs

is how it should look now

any recommandations for using d3 with om ?

exact same for d3 in Om

Untangled is using stock Om for everything UI...state management decisions are all we're making

ahah, was not using clojure at that time, but I’ll check

yes but d3 has it’s own diff algo right ?

the devguide for Untangled shows d3, and I think that will work with stock Om next

yes, you have to give d3 control of that part of the DOM

ok, that’s why you have to turn shouldComponentUpdate to false

?

Yep

ok ok, but IQuery u/InitialAppState should be the same

?

(componentWillReceiveProps [this props] (render-squares this props))

does the render update before the actual render

and then S.C.U. short-circuits the React render

ok

so you can pass data through, without REact rendering

the other Untangled/Om state management stuff can be leveraged to do the data from above, sure

right that’s great, other than that, have you find other special cases with d3 ?

Other than it is a pain to use js libraries of that complexity from cljs 😉

lol

is that a js/Object or a cljs map?

cljs map

which I have to #js `

exactly

nested

so, wrapper functions are nice. There are wrapper libs too

but other than that, have not noticed any difficulties. Don't use it heavily

right but my customer heavily use data viz...

*want to use ^^

sure

and I don’t have to have js and cljs for the same project

*don’t want

Hey all. Some time ago @ethangracer moved on to a new job, and he had gathered up "Companies using Untangled" along with some quotes we could use on the website. If any of you are willing to let us add you and your comments to our website please email me at <mailto:[email protected]|[email protected]>

the list got "misplaced" in his transition

Sorry 😬

oh, no worries

Pretty sure the list has grown anyway

Found the testimonials!

oh, nice

so, if you'd already given Ethan one, let me know if you want to update it. Otherwise if you're newer, go ahead and email me 🙂

argh...can anyone tell me a set of rules for defining macros in cljc files that actually work right with :require 😞

I seem to get all sorts of erratic behavior...like I can reset autobuild and they suddenly start working

stupid crap like that.

guessing it is still buggy, but don't discount my own possible ignorance

seems like if I go back to the :require-macros bit it works

but I thought the new support was supposed to allow :refer for both now

@jasonjckn @mitchelkuijpers Did either of you have permission for us to use your company name/plug on a website?

you can PM me if that is more appropriate

@pithyless @baptiste-from-paris untangled-ui should work now

ok, thx

I'm thinking it might be nice to allow/encourage people to add components that render with other CSS toolkits into the namespaces of untangled-ui. E.g. in the buttons namespace, perhaps have the default ui-button be the one that uses the framework, then allow bootstrap-button, etc. Another approach would be to make rendering into an internal multimethod where one could set some global like *ui-framework* to :bootstrap and, if available, the component would just naturally use the alternate rendering.

this is kind of a "ground floor" decision. Love to hear comments/ideas

I'll add a devcard that demonstrates what I'm thinking at least

Here are my musings: https://github.com/untangled-web/untangled-ui/blob/0f79e5883e0e4a0865c9144197f91239b854c8c5/src/guide/untangled/components/pluggable_css_exploration_cards.cljs

Basically, I'm strongly leaning towards allowing people to add support for their fav CSS framework, but either in a namespace or with function name prefixing. My conclusion is that trying to make a unified API will lead to more complexity and headaches than it is worth. I'm guessing people will rather just make their own library in general, but I'm open to having the components here. There is probably quite a bit of code re-use that can happen for more complex components (e.g. like image library).

but for simple things like button, it just doesn't make a lot of sense. There's nothing really to re-use since the attribute maps and possible DOM wrapping vary so much

I would prefer to stick to one “css” framework before starting to support a bunch of them. It’d make more sense to get a rich set of components out of the door

Yeah. I think with any of the frameworks the goal is that you can customize to suit your needs anyway, so as long as it's obvious how to do that I don't see a reason to make the framework choice itself customizable.

agreed. ok. I'll finish touching up a few examples

doing a bit of refactoring

@mahinshaw https://github.com/untangled-web/untangled-spec/issues/34

@adambros Thank You! That would be freakin sweet!