This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-21
Channels
- # arachne (1)
- # aws-lambda (50)
- # beginners (10)
- # boot (59)
- # capetown (4)
- # cider (9)
- # cljsjs (27)
- # clojure (249)
- # clojure-berlin (8)
- # clojure-finland (7)
- # clojure-germany (1)
- # clojure-italy (6)
- # clojure-nl (7)
- # clojure-russia (91)
- # clojure-spec (100)
- # clojure-uk (61)
- # clojureremote (2)
- # clojurescript (171)
- # core-async (11)
- # cursive (31)
- # data-science (1)
- # datascript (2)
- # datomic (11)
- # dirac (2)
- # emacs (16)
- # events (1)
- # hoplon (142)
- # juxt (4)
- # lein-figwheel (9)
- # leiningen (10)
- # luminus (7)
- # lumo (44)
- # mount (3)
- # off-topic (150)
- # om (18)
- # onyx (5)
- # perun (12)
- # planck (12)
- # protorepl (13)
- # re-frame (28)
- # reagent (8)
- # ring (1)
- # ring-swagger (10)
- # spacemacs (2)
- # specter (11)
- # sql (14)
- # untangled (99)
- # vim (18)
- # yada (2)
The develop branch of untangled-ui was just updated. I revamped the server delta a bit and wrote a quick doc guide page for it. I'd appreciate anyone looking over the docs and seeing what they think (@baris or @torkan ?) https://github.com/untangled-web/untangled-ui/blob/develop/src/guide/untangled/ui/Forms__03_Server_Integration.cljs
Does anyone else have the problem that IDEA/Cursive wants you to generate stubs, yet that fails? I've taken the css cookbook recipe into its own project and can't generate the stubs. The underlying error message is a Figwheel Configuration Error that the required key :cljsbuild
is missing. My problem is that it is there and I can see it.
@cjmurphy I have seen the problem before. In my case, it was a dependency problem. But either way, if you have a lein
error, Cursive is not going to be happy when it tries to generate stubs. If you can't figure out what's wrong, post your config and someone can probably help you find the issue.
At the top level there is a def
of figwheel config that reads the figwheel config. That is what breaks it
please let me know where you got that breakage from, so I can fix it if it is still in one of our repos
(ns clj.user
(:require
[clojure.set :as set]
[clojure.tools.namespace.repl :refer [refresh]]
[figwheel-sidecar.system :as fig]
[com.stuartsierra.component :as component]))
;;FIGWHEEL
(def figwheel (atom nil))
(defn start-figwheel
"Start Figwheel on the given builds, or defaults to build-ids in `figwheel-config`."
([]
(let [props (System/getProperties)
figwheel-config (fig/fetch-config)
all-builds (->> figwheel-config :data :all-builds (mapv :id))]
(start-figwheel (keys (select-keys props all-builds)))))
([build-ids]
(let [figwheel-config (fig/fetch-config)
default-build-ids (-> figwheel-config :data :build-ids)
build-ids (if (empty? build-ids) default-build-ids build-ids)
preferred-config (assoc-in figwheel-config [:data :build-ids] build-ids)]
(reset! figwheel (component/system-map
:figwheel-system (fig/figwheel-system preferred-config)
:css-watcher (fig/css-watcher {:watch-paths ["resources/public/css"]})))
(println "STARTING FIGWHEEL ON BUILDS: " build-ids)
(swap! figwheel component/start)
(fig/cljs-repl (:figwheel-system @figwheel)))))
@tony.kay: Yes that fixed the problem. It was in the Cookbook, the example for the css (obviously possibly the others too). The user.clj is old code: https://github.com/untangled-web/untangled-cookbook/blob/master/recipes/css/dev/server/user.clj. Also the css example project.clj uses "0.5.5" of figwheel-sidecar, not "0.5.9".
Yes I'll test them all fix if I can, certainly this (css) one anyway. Right now trying to start a Figwheel REPL has got me stumped: "Error: Could not find or load main class script.figwheel.clj". The thing is I've defined the local REPL in IDEA and the working directory and JVM args are correct, so script/figwheel.clj
should be being found.
Hey @tony.kay the new documentation on the forms support is great. I think the basics, server-integration and full-stack-demo devcards are a great starting point for everyone who wants to use the forms support. Is the devcard "05-field-interactions" WIP? It's confusing me.
I'm working on making validation a little more clear...adding a would-be-valid?
function
You changed the source-paths in the project.clj
and this configuration doesn't work for me when
I start the "guided-demos" with the following command.
I get some compile errors that some files could't be find and loaded. Anyway that's not a big deal at the moment.
could be I already fixed that...my builds are all working, but I have not pushed today
In the previous version, when I commit the changes to the server mutation, I only got the ":delta" in the params.
Something like that:
{:delta {:tx/set {[:event/by-id 2] {:event/title Title 22}}}}
Now, I get get the hole "Forms" Data (Elements, etc.) but the delta is also included in the map, so it works for the moment.
Here is an example output from the params value in the server mutation:
{:form {:db/id 1, :event/title Title 12, :event/desc Desc 1, :untangled.ui.forms/form {:elements/by-name {:event/title {:input/name :event/title, :input/default-value , :input/placeholder , :input/css-class input, :input/validate-on-blur? true, :input/type :untangled.ui.forms/text}, :event/desc {:input/name :event/desc, :input/default-value , :input/placeholder , :input/css-class input, :input/validate-on-blur? true, :input/type :untangled.ui.forms/text}, :db/id {:input/name :db/id, :input/type :untangled.ui.forms/identity}}, :ident [:event/by-id 1], :origin {:event/title Title 1, :event/desc Desc 1, :db/id 1}, :subforms [], :validation {:event/title :valid, :event/desc :unchecked, :db/id :valid}}}, :delta {:form/updates {[:event/by-id 1] {:event/title Title 12}}}}
I didn't had the chance to dig into the code....but I guess there is something not ok with the diffing stuff?
I did fix that, and it should be on develop, unless someone caused a regression with a bad merge in git
my version is from ur last commit 35c19d40192c0664165aa445c4766c6992b74553
“updated docs a bit"
something I did caused git to lose it's mind. I think I did a rebase, and that probably screwed it
I'm renaming the keys already, so anyone using it is going to have to touch some code
the only interesting keys are the updates, new-entity and so on....so delta is unnecessary
Sometimes I use the state threadding in a mutation/swap! to modify the app-state like this
integrate-ident!
caused some unclear errors about IDeref...it took me a while to figure out that
I misused`intgrate-ident!`. I think it is an easy fix to check if the "state" is an atom or not and then
use swap!
or not in integrate-ident
. Could probably safe a lot of time for others when they are in the same situation.
I like composition. Let's think about this a bit. The integrate-ident!
function was meant to be a helper for post-mutation loads that wanted to target data into the app state. Um, I think I'd rather do this (which is similar):
1. Make the !
form have an atom assertion, so it will fail fast with a good error message
2. make a non !
form that takes state as a map and returns new state, and re-factor (1) to be it/use it
then you have both, but not API confusion about the !
meaning "internal mutation lives here"
still have some headache on how to integrate image-upload into the forms or in general to upload a file within untangled/om.next. Would appreciate to have some more hints on that in the near future.
basically we just did a base64 encode of the uploaded element and encoded that into a mutation param
a mutation to send the file (that also updates app state to show uploading spinner), followed by a follow-on remote-read in the same Om transaction with a post mutation that hides the upload...use a UI tempid in the mutation, and include that tempid in the follow-on remote read.
Here are the ideas: 1. You're going to want to know the identity of the uploaded thing from the server. Use tempids for that. You make some kind of thing in your app state that HAS that UI generated tempid, and send that tempid with the upload. The server mutation sends back the tempid remapping. Now you know the ID of the upload on the server
2. A single transaction can include both reads and writes. Reads in Untangled use the load mutation. So something like this:
(om/transact! this `[(upload ~{:base64 data :filename "boo" :id some-om-tempid}) (uc/load { ...query with same tempid...})])
3. The network stack of Untangled sends writes before reads (no sense in reading stale data). The response from writes WILL REWRITE tempids in the network queue
So, your follow-on load will have the right real ID...so you could query for status about the image.
You could also use a return value handler to handle app state changes you might want to make after the upload is done
Remember your UI is still going to be unblocked during all of that. So you might need to set app state to prevent leaving the page/submission until upload is complete.