This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-11
Channels
- # adventofcode (7)
- # aws-lambda (1)
- # beginners (161)
- # cider (19)
- # cljsjs (5)
- # cljsrn (30)
- # clojure (80)
- # clojure-korea (2)
- # clojure-new-zealand (8)
- # clojure-russia (73)
- # clojure-sanfrancisco (1)
- # clojure-spec (14)
- # clojure-uk (12)
- # clojurescript (84)
- # cursive (7)
- # defnpodcast (8)
- # dirac (16)
- # events (2)
- # garden (7)
- # hoplon (178)
- # off-topic (2)
- # om (58)
- # om-next (2)
- # onyx (21)
- # pedestal (1)
- # planck (15)
- # protorepl (32)
- # re-frame (31)
- # untangled (1)
- # yada (5)
@micha sometimes I miss the ability to have lenses on a loop-tpl
/`for-tpl`, do you see a problem allowing it?
It shouldn't always work but if I make sure that coll is a vector of something that implements the (assoc c idx v)
it could be a useful thing.
Yeah, that's what I was thinking. Do you see some problem with performance or other practical impediments?
Is there an easy way to make castra give you more information in an error than #error {:message "Server error.", :data {:castra.core/exception true}}
?
Hello Hoplonians, as a holiday 🎁 this year I am donating my time to you! https://medium.com/degree9/pre-clojureremote-17-year-end-cleanup-e829757a1f89?source=linkShare-a2d5aa46d2e3-1481424862
@micha thanks, trying to give back to this amazing community!
@flyboarder if you have the cycles and would be interested, http://hoplon.io could use some love
it's made w/ hoplon, but has some jank CSS goin' on
@alandipert whats wrong with the CSS?
looks crappy on ipads and phones
the guy who made it originally did a nice job with it, but something was lost when i hoplonified
oh right - yeah, the examples don't flow properly when the window is made narrow on desktop or mobile
@alandipert it would be great if we could get KLIPSE fully working in Hoplon, that way we can use it for the examples
oh man, yeah
i thin mynomoto made some progress there
@mynomoto what is the status of KLIPSE and Hoplon? Is this something we can try and complete as a Holiday gift to the community?
i'm totally down to help with that, i'll have a lot of hacking time next week
aaaah let me know if you get KLIPSE working @alandipert @flyboarder
very interested in plugging that into my component library
@alandipert i can help fix the css on the hoplon site if you want
@flyboarder mk! looks cool 🙂 although i can’t think of anything to use it with off the top of my head
Speaking of externs @micha, I had to go back and do the whole foreign lib thing for jQuery.minicolors - I got it working fine using the approach you helped me with the other day. And then I deployed it to my staging site. Which uses advanced compilation. And it broke in confusing ways. So now it’s done properly. 🙂
@candera i'm interested to hear more of your thoughts about javelin on the server sometime
@flyboarder @alandipert I didn't had time to go back to Klipse on Hoplon other than research the problems. So basically macros needs to be rewritten in cljs itself. The one that looks more troublesome is the string interpolation, other stuff seems more direct.
@flyboarder It would be amazing if you get that to work. I just deleted stuff that stopped if from working at all.
@mynomoto I'd be willing to give it a go! If my understanding is correct, because we dont have access to clj we need to rewrite all the macro's correct?
@flyboarder that's basically it.
the compiled js will need to include a lot of runtime that is compiled at build time that will now need to be compiled at runtime
@flyboarder some of it is straightforward, but other parts may be trick if we depend on java things.
@meeli that would be really helpful re: css! if you work on it and have any q's, let me know
@flyboarder the working version with no macros working is https://mynomoto.github.io/hoplon-klipse/
i forgot also that i explored driving the hoplon task as a castra endpoint and made a little progress, but i think i trashed the code. was straightforward-ish. micha and i hacked on that a bit before realizing it felt like only a little more work to port the damn thing to cljs
@micha you use cljc files for macros and the #clj version will be used for the clojurescript compiler and the #cljs version for the bootstraped version.
@flyboarder https://github.com/mynomoto/hoplon-klipse/blob/gh-pages/index.html#L21 points to the repositories I'm using. I think the only things I did was deleting stuff until it worked.
@micha I think this is the relevant part for macros: https://github.com/viebel/klipse/wiki/How-to-make-a-clojure-library-self-host-compatible#reader-conditionals
at least we know it should be called restructure
Yeah, don't think there is a way to avoid that. Unless everything is a lens which is overkill.
I'm looking at your form machinery now. You don't validate fields one at a time right?
so the backend could fail validation for eg password confirmation doesn't match or things like that
the backend is plenty fast enough to handle all of the validation in real time with no perceptible delay or lagging
for the above to work smoothly you would want to have the backend rpc functions or whatever accept a map of arguments instead of positional ones
We already do have client side validation on work that happens on blur of the field, I'm looking for an abstraction for that. I have one, but I'm looking around for a better one. Not related, I like that map of cells but that makes harder to create formula cells using those right?
you can end up with ugly things like (cell= (doit ~(:password (:errors machine))))
or something
I used a result cell with {:success {:server-data ...} :error {:server-error ...} :form {:form-data}}
don't remember having much trouble with it.
Yes, and things should always be in the same path except for the first one that is the type of data.
@mynomoto sorry was in a video call, I will look into the klipse stuff thanks!
@flyboarder np, it will be awesome if you make progress on that!
@micha I will try to put something together. I'm currently working on a datascript version where the db is the only cell that is not a formula and seeing how that works. If the baby helps I may put something on github later today.
the idea is that some efficiency can be gained by knowing that the formula is a constant
@mynomoto: if you have a generic cell feel free to submit it to the brew repo!
in the above example if barp
is a constant then you can just set the div's id, you don't need to add the watch
Very cool
So if none of the arguments to formula are cells... Why would formula return a cell with a constant attr instead of just not returning a cell?
I guess it needs to maintain the contract
I guess an atom would work
But still, backward compatibility
https://github.com/hoplon/javelin/pull/31/commits/191fb59344b7346c88b3cc5e1a5c21ea1939b282
Oh, yup
I don't think the advantage of not needing a new field outweighs importance of returning the same type if we can help it
Change is very small anyway
Also the memory implications are probably the same
Ie I don't think returning an atom would make it more efficient on any way
@micha: what's your thought on splitting the cljs stuff out of boot-hoplon, I realized the ability to create a DSL like the .hl files and what we are putting on top of it with hoplon could be factored apart
I think it could be beneficial to the cljs boot community to be able to make our own DSLs like that
Well it's in hoplon now
It feels like the boot task is doing 2 things that could be used separate
Is there a function that will show, in a repl, the html that will be generated by an element? Or is it better to just throw it up in the browser and inspect it?
@grant html is not generated there is no way to do that
Elements are created and attached to the DOM at runtime