released untangled server 0.6.0 — this is a breaking change release, see complete changelog in the repo

some of the changelog: - :authorized-routes => :unsecured-routes - should be a bidi route map to :ok handlers (enforced on system start) - top level files are always unsecured - root route "/" is also always unsecured - to unsecure a whole sub-route (eg: the js folder) use bidi's catch-all routes, eg: {"/js" {true :ok}} - Open id mock will now deal with multiple users. "user" can be passed as a query param to the open id mock endpoint. - Fixing heisenbugs wrt datomic not sorting & protocol-testing randomly failing - Adding invalid-token-handler to the :openid config - Takes a request whenever an invalid token is passed to a secured-route (ie: not an unsecured-route) and should return whether the request should be allowed to flow through the handler stack (defaults to false)

@ethangracer: Is that on clojars?

good point, probably not yet, will need @tony.kay to do that

unless someone else has access

I don’t think so

(defui B

    static IQuery
    (query [this]
      `[:which-tab
        {[:link-a :global] ~(get-query A)}])

    static Constructor
    (initial-state [_ _]
      {:which-tab :messages})
    )

Is there a way to to initialize state of A here, or just use merge-state! ?

0.6.0 server on clojars

@jasonjckn: If it is a root level thing, compose it into root component state

thanks

it doesn't "belong" to B

B just uses it

it doens't really belong to Root either...but I see no problem with putting it there

@mahinshaw: should probably elaborate on how to upgrade to use your change of [:openid :sub] to [:openid :users] in the config

@adambros: I was hoping that you would do that 🙂

@jasonjckn: Actually, since there is no query to normalize that global thing (which could be nested), it does make more sense to use merge-state! in the started-callback of the app construction.

hm, ok, that's what you recommended in tabbed example

yeah, just in the middle of several things...not thinking clearly

no sweat, appreciate the advice

If it's a singleton that you query with a link like [:thing '_] then it'd be ok to put it in Root (assuming that it had no nested content that needed normalization)

But because of those restrictions, you're probably better off just merging the state in at startup if it meets the "global singleton" criteria

since the merge function will normalize it and such

I'm expanding the merge-state internals a bit soon. At the moment it isn't compliant with how it should work in corner cases...e.g. I'm not doing the mark/sweep step and merging with something that might pre-exist

i'm trying to convert that example now to use the auto normalization ,

static IQuery
    (query [this]
      `[:which-tab
        {[:link-a :global] ~(get-query A)}]) to  
  static IQuery
    (query [this]
      `[:which-tab
        {:link-a ~(get-query A)})

oh, well, at that point it isn't top-level state anymore, and can go in your cnostructor

also note you really don't need the syntax quote

most queries don't need quoting at all

i'll keep that in mind, i'm trying to keep the syntax as regular as possible for my team

to us all these clojure things are intuitive

erm, they're going to have to understand quoting...might as well bite the bullet

well if I can make all queries without quotes i'll do that

i just want it regular

In Untangled you don't use query parameters or mutations in queries. You should not need quoting at all

which simplifies things quite a bit

mutations: those need quoting

you do need them in mutations

nods

unless you want to write [(list 'app/a)]

which you could alias to invoke

neat idea

[(invoke 'app/a)]

that would make it easier for them

then you don't need to teach unquote

:onSelect #(transact! T [(! app/choose-tab {:tab (keyword %)}) :ui/react-key])}

(defmacro ! [action-name & params]
  {:pre [(symbol? action-name)]}
  `(list (quote ~action-name) ~@params))

excellent, no more quote education 🙂

before you comment on :ui/react-key, it's on my todo list to remove it 😉

can you have multiple params? eg: [(app/a :foo :bar)]

afaik params have to be a map, so just just add more keys if need more data e.g. [(app/a {:foo “foo”, :bar “bar”})]

right so that ! macro should be

(defmacro ! [action-name params]
  {:pre [(symbol? action-name)]}
  `(list (quote ~action-name) ~params))

there's some bug in merge-state! or i'm using it wrong

(defui B
    static om/Ident
    (ident [_ _] [:link-b :global])
    static om/IQuery
    (query [this] [:title])
    static Constructor
    (initial-state [_ _] {:title "foo"}))

(defui A
    static om/IQuery
    (query [this] [{:b (om/get-query B)}])
    static Constructor
    (initial-state [_ _] {:b (initial-state B nil)}))

(defui D
    static om/IQuery
    (query [this] [:some-data])
    static Constructor
    (initial-state [_ _] {:some-data 3}))

(defui TabUnion2
    static om/Ident
    (ident [_ _] [:link-a :global])
    static om/IQuery
    (query [this] {:link-a (om/get-query A)
                   :link-d (om/get-query D)})
    static Constructor
    (initial-state [_ _] (initial-state A nil)))

so if I don't call merge state I get the following global state

:current-tab2 [:link-a :global],  :link-b {:global {:title "foo"}},
 :link-a {:global {:b [:link-b :global]}}},  :search-results2 {:global {:page-size 10, :type "message"}}

all this is expected

your union cannot possibly work right the way you've written it

you're ident function has to reutnr the right ident for the thing in state

oh i see

which means you have to add state to A and D to distinguish them programatically

i was trying to simplify the code that was having an issue, the original code had a proper ident

i'll fix that, see if I can still reproduce in a smaller example

ok it still reproduces

(defui B
    static om/Ident
    (ident [_ _] [:link-b :global])
    static om/IQuery
    (query [this] [:title])
    static Constructor
    (initial-state [_ _] {:title "foo"}))

(defui A
    static om/IQuery
    (query [this] [{:b (om/get-query B)}])
    static Constructor
    (initial-state [_ _] {:link-type :link-a
                          :b (initial-state B nil)}))

(defui D
    static om/IQuery
    (query [this] [:some-data])
    static Constructor
    (initial-state [_ _] {:link-type :link-d
                          :some-data 3}))

(defui TabUnion2
    static om/Ident
    (ident [_ {:keys [link-type]}] [link-type :global])
    static om/IQuery
    (query [this] {:link-a (om/get-query A)
                   :link-d (om/get-query D)})
    static Constructor
    (initial-state [_ _] (initial-state A nil)))

:link-a {:global {:link-type :link-a, :b [:link-b :global]}},
 :link-d {:global {:link-type :link-d, :b {:title "foo"}, :some-data 3}},
 :current-tab2 [:link-a :global],
 :link-b {:global {:title "foo"}}}

(uc/merge-state! app ui/TabUnion2 (uc/initial-state ui/D nil))

some how :link-d contains denormalized data about B even though D never mentions B anywhere

is that merge done in started-callback?

yes

makes no sense...possibly something else in your app you're not showing?

yah i mean there's other code around, i can try to reduce it to a simple git repo for you

So, I'm working on merge-state right now. I'll keep an eye out

The code you're showing is very close to my example, which works perfectly

so I cannot see how mine could work and yours not, unless you've got something somewhere else messing it up

@tony.kay: https://dl.dropboxusercontent.com/u/2387022/bugdemo%202.zip here's a project with just that code

@tony.kay: still reproduces it

thanks...I'll take a look in a bit...working on this function at the moment

kk, brb lunch break

looks like a straight forward fix the issue is here https://github.com/untangled-web/untangled-client/blob/2bcedfcd53a791200355f123e63ba3afada36534/src/untangled/client/core.cljs#L133

you merge inintial state of TabUnion2 with D's object data

TabUnion2 has no representation in state. It is either A or D

it is a switch that has no rep of it's own

(uc/merge-state! app ui/TabUnion2 (uc/initial-state ui/D nil)) ui/TabUnion2 is bound to parameter component, who's initial state is read into let binding empty-object

empty-object is merged with object-data at L133

ah

🙂

yeah, let me look at that...that's part of the thing I'm rewriting

but you're right, that logic isn't right for unions...but it wasn't right in general either 😉

cool, glad we're on the same page

Pushed untangled spec 0.3.7. Fixes rendering issues that started with latest React and Om

specifically, diffs were not working right

@jasonjckn: Pushed untangled client 0.5.3-SNAPSHOT to clojars with the work in progress. I'm done for the day, and the new version is "more correct", and mostly tested. I put a union fix in, but that's the bit I have not yet tested

much appreciated

I expanded the API so that one can access the ident integration code as a stand-alone function

and can do appends/prepends/replace as many times as you want (maybe I already had that)

Also does dupe checking on vectors, and mark-and-sweep

(of missing data)

it's doing garbage collection?

not sure what you mean by mark and sweep

it's an underdocumented, but important, feature of Untangled merge

I talk about it in at least one talk and the tutorial

which tutorial?

The Untangled Tutorial

ok i'll check it out

http://untangled-web.github.io/untangled/tutorial.html#!/untangled_tutorial.H_Server_Interactions

The bit about data merge

oh btw if it wasn't clear we're moving ahead with untangled for our app 🙂

great!

The data merge stuff uses a mark-and-sweep algorithm to implement the behavior of data merge descritbe in that tutorial page

The merge-state! function adopts that as well to ensure consistency...that's the bit I forgot on the first pass

ok, excellent

the data merging looks super useful

i've used it a tiny bit so far, and it's great

I was also considering posh & datascript

but so much boilerplate around maitaining that and merging

The new merge function is really mostly targeted at server push and startup. That's part of the reason I split out the ident integration code as a utility function.

Responses from teh server are already merged properly (except for peppering about the idents)

kk, potentially we'll be doing server push in v2

I may split it out a bit more...at present the ident editing requires a reconciler, which isn't right

for use in mutations

So probably need two versions

The one I wanted here queues re-renders, since on server push you'll want that

right yah

So, still a bit more cleanup to do before releasing as an official part of the API

cool, i'm going to handle all the difficult parts and compatibility changes for the app, just need to get people productive with render functions, and simpler parts

Nice thing is: there aren't many non-simple parts 🙂

yah and, they're already react/javascript engineers, and om.next/untangled doesn't try to abstract react

like reagent does

nice for you

I think the constructor addition really cleans things up quite a bit. Our devs are really happy with the improvement

(as am I)

yah i got rid of passing in hand normalized data, so far so good

i like it, would be interesting if I never had to called merge-state! for example with TabUnion, but i can't think of any better designs

I can, but I'm not sure it's fully general

there's a to-many and to-one case

for unions: to one

for hetero lists: to many

Not had time to think it through

nods

"Constructor" is going to confuse java/javascript people

It probably makes sense to require the constructor to return a map of data

oh right...might not be the best name

I'm open to suggestions

InitialState?

that's definitely better

i'll let you know if I come up with something

k