Clojurians Log v2

I’m not certain how I would test SSR with merge alt unions, given that the alternates cannot be reached unless you run the app. The main path is always initialized (e.g. the default branch of the union). I think that’s why I originally hadn’t bothered porting it. Oh, but then perhaps SSR wasn’t working because the symbol was missing? Anyway. It is ported

Untangled spec alpha4 snapshot pushed to clojars. Server-side tests rendered in the browser now show compile errors (in the browser). These were getting swallowed, making it hard to fix a test when there were syntax problems.

@adambros has a fix for sorting (failing specs don’t maintain order). I expect a push soon.

I have put some of the code from here: https://github.com/awkay/untangled/blob/d6fe2a49cfb21ce16e6a8e521a710bd0d61fb654/src/devguide/untangled_devguide/O01_Forms_The_Basics.cljs into my own application. To the add-phone mutation I've added (remote [env] true). (Just as an experiment). Was hoping to see the same mutation on the server side being called. Instead I'm seeing 'Cannot write Function' as a client side error message in some stack trace that includes marshalling. I'm guessing the solution will be to muck with the AST and get rid of this mysterious function so it doesn't get sent across. Probably my next step will be to look at what the send function is actually trying to send across, looking for anything that isn't just data. Anyone experienced this before?

@cjmurphy that probably means you have a function in the form state somewhere which it is trying to marshall to transit

So I would print the state and see where the function is in the app-state and see if you can remove that (since you should not put functions in your app-state

Also i would not add remote true to add-phone but use the provided function from form-support to persist the entity

commit-to-entity!

Thanks @mitchelkuijpers. I checked my app state and no function inside. However as you point out I was taking the wrong approach anyway. I looked for the commit-to-entity! call and just added in :remote true, so call from the [Submit] button is now #(f/commit-to-entity! this :remote true). I found the instructions as to what to do on the server side here at /src/devguide/untangled_devguide/O03_Forms_Server_Integration.cljs.

Everything seems to work when I press [Submit], however I don't see the message "Mutation for ", that was hoping to see.

@cjmurphy Do you have a [untangled.ui.forms :as f] required in the namespace where you defined the f/commit-to-entity

Yes I do.

At first I tried a defmutation but the f part at the beginning failed the spec for defmutation. So I looked up server-mutate as the actual name of the multimethod.

Not sure how that part works we don;t use that yet we have defmethod on our own defined mutate multimethod

There would have been a complaint if no method defined for f/commit-to-entity.

Actually that is not true. I took away the particular defmethod/defmutation altogether, and no complaint. So it is still likely I just haven't been able to set it up right.

@cjmurphy You’ve got the right shape. Commit only sends a delta (so were there edits?)

The 010 Full Stack Demo is still working, I assume, and it shows both client and server code.

Yes I'd better try out some working code. I just gave the person (you!) a new phone number (like a few numbers, like 55555 - not a proper US phone number) and pressed [Submit]. There seems to be a silent failure somewhere. Perhaps in copying across I didn't get all the validation hooked up properly - I'll make the validation be sumfin easy like single digit and make sure 'bad validations' are thrown up before looking at the mutation across the wire. I know the networking is working fine as reads are coming across.

I worked it out. The problem was I was using timbre/info on the server rather than trusty println.

Untangled Spec has been migrated to my namespace. Repository is now here: https://github.com/awkay/untangled-spec

@tony.kay will start playing with SSR for my use-case 🙂 thank you.

is the u-spec migration temporary or is that it’s new location ?

depends on Navis. They are not maintaining the untangled-web github group, but they technically own it. So, I’m forced to move things I’m going to maintain to my namespace at the moment. If they ever give me some kind of written permission to use the untangled-web accounts on github, then I can use that, which would be preferable since that is where ppl know to look and search engines point to

I could rename untangled and make a new group (untangled is already taken, as is untangled-web)…but I’d still want them to at least take down the out-of-date resources.

but they do not seem in any hurry to do anything…even return my emails

Both Untangled and Untangled Spec version 1.0.0-beta1 just release to clojars. NOTE: New dependency name for spec. https://github.com/awkay/untangled-spec https://github.com/awkay/untangled

The contributing guide was also updated for Untangled to tell you how to run tests for server and client

ohh 😞 would be awesome if they accepted, github starts usually factor in to choosing a library also, but not that big of a deal as long as the repo is active 🙂

how do you measure a start? it isn’t a fork, and the commit history goes back to 2015

but I do have some hope that they’re just busy and will come around. In the meantime, I want the project moving forward

agh sory typo meant github stars 🙂

ah…yeah, those are nice to have

Hmm - it wasn't actually timbre/info to blame. It was me not realising that only way to get the data to the server was to press [Validate] then press [Submit]. Just [Submit] alone was doing nothing.

@cjmurphy Yes, you should make sure you understand the design. Validation is a separate step under your control.

The fields are tri-state, so auto-validating the whole form all the time would cause errors to show up on fields the user has not interacted with yet. So, you need to hook in logic at the appropriate point (event) and run whole-form validation…and not light up “submit” until that has happened, and all is valid

Or you could light up the submit button, but make sure the transact on it checks validation before trying to really commit

Yes I don't need any validation for the moment. I just assumed that for the code I copied across if you just hit [Submit] then validation would happen automatically. Something I'm stuck on right now, separate issue: Is it okay to call df/load from a mutation? I'm thinking to pass in the component to the mutation because of what df/load needs as its first parameter.

The mutation in question is populating a drop down. But needs to do a load for the selected value of the drop down.

I found this text: "By contrast, load-action, load-field-action, and load-data-action do not call om/transact!, but can be used to initialize a load inside of one of your own client-side mutations." So seems like I need load-data-action, as need to construct a query to get exactly same behaviour as load: [({server-property (om/get-query SubqueryClass)} params)]. But load-data-action no longer seems to exist in untangled.client.data-fetch. Been renamed, rationalised?

load-action

all of the load-data was deprecated a while ago. I need to update the docs. In the 1.0 release I finally removed it.

If there is any kind of outcry I can add it back. I think the API story is clearer without it though.

@cjmurphy

Also, did you watch this video? https://www.youtube.com/watch?v=mT4jJHf929Q&list=PLVi9lDx-4C_T_gsmBQ_2gztvk6h_Usw6R&index=8&t=85s

Polishing documentations and doing a lot more stuff with forms is next on my list.