This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-28
Channels
- # aws (7)
- # beginners (69)
- # boot (67)
- # cider (9)
- # cljs-dev (159)
- # cljsrn (2)
- # clojars (25)
- # clojure (345)
- # clojure-austin (9)
- # clojure-berlin (1)
- # clojure-dusseldorf (10)
- # clojure-italy (3)
- # clojure-nl (1)
- # clojure-portugal (1)
- # clojure-spec (73)
- # clojure-uk (59)
- # clojurescript (163)
- # clojurewerkz (1)
- # component (26)
- # core-matrix (2)
- # cursive (20)
- # datascript (32)
- # datomic (15)
- # dirac (16)
- # emacs (3)
- # hoplon (35)
- # jobs-discuss (87)
- # jobs-rus (95)
- # luminus (15)
- # om (135)
- # om-next (3)
- # onyx (47)
- # pedestal (67)
- # perun (74)
- # play-clj (4)
- # portland-or (1)
- # proton (4)
- # re-frame (13)
- # reagent (18)
- # remote-jobs (17)
- # rum (20)
- # specter (11)
- # untangled (101)
- # yada (18)
strange. You should look through the generated uberjar (i.e. generate one locally and run jar tf file
on it)
I don't remember what goes in there. I think uberjars are exploded, and often the clj files are compiled into classes.
sometimes classpath :exclusions can drop it (e.g. it is in dev, but not prod profile)
I've also seen weirdness when a lib (source) gets accidentally included inside of another one
or different versions get included, and the one that ends up compiled in is an old version
i understand it gets hairy thats why im developing my skills to look in the uberjar and the loader etc
My guess is if you analyze what is pulling in component, you might find it is resolving through :dev profile
if it is already there, then that worries me a bit. Anything in your top-level deps should take precedence in all envs
https://gist.github.com/anonymous/d092e747bc9d6e358afbc61cef5e137f in ex5, @reconciler has entries for :person/by-name in ex6, @reconciler does NOT have entries for :person/by-name my question: how does @reconciler know about :person/by-name ? I see that it's defined in defui Person .... but I don't see how this info is passed to reconciler
@tony.kay Thanks for adding the form argument to the validator. I now have access to the form field values to be leveraged in the multimethod to f/form-field-valid?
(defmethod f/form-field-valid? 'less-than-value-valid? [_ value {:keys [untangled.ui.forms/this-form field min max]}]
(let [value (int value)
field-value-to-test (f/current-value this-form field)]
(and
(<= min value max)
(< value field-value-to-test))))
(f/integer-input :range-question/minimum-value :validator 'less-than-value-valid?
:validator-args {:field :range-question/maximum-value :min 0 :max 5})
Hello. Just wondering, are there any docs or example apps on how to do server side rendering with untangled ?
Query is: I'm given these props. How do I select the part of it I care about? Ident is: I'm given these props. How do I derive an ident from it (this will correspond to where this ident is stored in the graph databse).
@claudiu Not yet. I swear I wrote something as a quick demo, but I don't remember where. Needs to be a cookbook recipe
so, any example that works there would work for Untangled. You'd just render to string using the root node and a props tree.
Our InitialAppState would make it a bit easier to get an initial state for that, but otherwise identical
Working on a reusable file upload component. I'm also adding support for multiple remotes in client, which will assist with these kinds of components.
having a tl;dr confession moment... I'm having a hard time reconciling in my imagination how to work with typical REST services/microservices and the type of server/client syncing that untangled provides... can anyone summarize or direct me to resources to help clear this up?
I'm used to pedestal style swagger dealios
@macrobartfast Two possible choices come to mind:
1. Implement UntangledNetwork and provide that to your client. Your send
implementation would convert the EDN requests to REST calls, and translate the responses to properly structured EDN for giving to callback that send is given (which merges the result for you)
2. If you own the services, use the normal network stack that comes with Untangled and do back-end integration with the real data instead of using the REST. Part of the point of data-driven apps is you want the client query to be the network protocol
Om Next (and therefore Untangled) kind of assume you want to avoid REST for the most part, and want an overall better model. So, our story for REST integration is present, but not primary
3. Use the normal Untangled network stack to wrap up your standard REST services - translating EDN requests into REST calls as necessary (and caching the data if you want), if those already exist (this is the option we use)
Ah, I thought you were implying talking directly to the databases instead of using REST though.
if you're using the whole stack, does that mean you're going to one server, then talking to another?
Yeah. We're in a somewhat unique position though - we already had the RESTful api built out and have another application built relying on it.
that is going to be common, I just don't understand why it is easier to proxy to REST than it is to just implement calls to the functions that the REST API uses to build the responses...YMMV 😄
at that point why not just do the REST translation layer in the client, as in suggestion (1)?
Yeah, definitely a mileage-may-vary situation. For us it was easier because all of that code lives in a Ruby app. And proxying has benefits because we get the opportunity to cache and store the data into datomic and usually serve that instead.
Making it more UC <-> US (sometimes to get more data: <-> REST)
that was really helpful, thanks!
@macrobartfast the networking stack is in untangled.client.impl.network. The protocol is public...the namespace name is an unfortunate legacy oversight
My tongue is bright orange from all the architecture decoupling kool-aid I drank, and I associate REST interfaces with that, so it's a bit of a brain warp to think about the more direct approach.
For instance, building out an app server to support a web app, a cli tool, and a couple native mobile clients...
it seems like the REST approach might be better down the road, but I think I'm not grokking something, no doubt.
Here is a possible architecture:
Webapp <----> US <--------|
|
CLI <-- REST --> XLATE -->| Common Access API
^ |
Mobile <---+-- or------ ------->|
bleh...you get the idea. Mobile/cli could talk to REST, which is a thin layer over top of the real APIs that get/manipulate the data
webapp in Om/Untangled uses the read/mutate Om parser technique on the server, and uses the same common API layer
that would be the best of both worlds, then
lol, took the words out of my mouth
yeah, because I'd much rather go in that direction than native
*native mobile apps
and re cljs in node, exactly
aight, that's reassuring and helpful
I'm using the client routing code in 0.7.0 and it appears that it breaks the app-state database in some way, I've got a ui/menu-active in the root of a screens query and I'm trying to toggle it with ucm/toggle!. It does toggle part of the app state but it's the state described by the screens ident rather than the state that's held and returned in the screens query which stays the same (the value set in the initial-state)
I established the bad habit in the early days and a lot of our docs have examples with non-namespaced keywords that tend to lead to this problem
I don't think that's the problem as I can't find any ident collisions (I only have two screens - a login and message screen) Should the ident of each screen correspond to anything that the router knows about (implying the screen knows where it's placed in the router)?
which must be obtainable from the data in the object itself, since the ident function on the router reads it
In other words, the ident
function on the router is the ident function for the screens it routes to
that's how the queries resolve: the "current ident" of the route also "routes" the query
so, their state must be set up so that the ident on the router returns an ident that has the screen "name" as the first member
I believe the docs say this, but it is an unfortunate fact that all of those things have to align 😕
okay, I think I understand a bit more now, I'll recreate a simple test case so I can examine what's going on a bit more 🙂
Here's something I continue to not understand. 1) We can pass in data via props / computed. 2) Why do we have an extra component for defining queries to pull in more data? 3) Why not send in all data via props / computed ?
@qqq Tony talks a bit about computed in this video https://youtu.be/fH0DX0Dubx8?t=22m34s
@qqq you're number (2) does not make sense to me. Too many possibilities for what you mean.
the answer to that is the main central defining quality of Om Next...so you should watch more David Nolen talks...or perhaps stuff on Facebook's Relay or Netflix's falcor
@tony.kay: That's an accurate deciphering of my question. The point I'm now confused on indeed is: "why have queries at all? why not pass all data through props/computed entirely"
qqq: queries specify the data that becomes the props