This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-12
Channels
- # beginners (36)
- # boot (11)
- # cider (10)
- # cljs-dev (10)
- # cljsrn (3)
- # clojure (103)
- # clojure-greece (1)
- # clojure-italy (16)
- # clojure-nl (3)
- # clojure-spec (59)
- # clojure-uk (129)
- # clojurescript (125)
- # data-science (29)
- # datomic (30)
- # emacs (12)
- # events (5)
- # fulcro (61)
- # graphql (5)
- # keechma (3)
- # leiningen (9)
- # luminus (7)
- # onyx (26)
- # re-frame (3)
- # reagent (56)
- # reitit (25)
- # ring-swagger (16)
- # shadow-cljs (44)
- # spacemacs (4)
- # specter (2)
- # tools-deps (7)
- # vim (8)
The problem I am hitting has been captured here, but I will try with the vanilla compiler as well: https://github.com/thheller/shadow-cljs/issues/304
Yeah I feared that and thanks for confirming. For some moment I thought that it would be idempotent to require core twice.
so I’m trying to hand React a fn that I added meta-data to, and it’s throwing an Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.
Okay Clojurians... I need some real-world advice to make an argument to colleagues as to why we should use Clojure(Script) instead of Angular (6) for our big, non-traditional web app
and we are in greenfield territory on front and back end. Nothing legacy, we have officially stopped development on our current product (only support and very major bug fixes).
It's not a question of "can I do it in CLJS", we know we can. It's just that my colleague who is the senior FE dev (and truly, is more experienced and competent in that area) doesn't want to take the risk, and doesn't see the point. Fortunately our boss is more open-minded, but I still think it is correct to defer to the senior FE dev who will shoulder the responsibility and major work load. We are a small team, and I think Angular is logically Java, only worse because it's in framework-ese. I despise JS frameworks because they are neither imperative nor functional programming, hard to reason about, the opposite of simplicity.
well I don’t know if there’s much real risk, people ship stuff with ClojureScript all the time
We all have extensive typed language and dynamic language background. None worked with TS, nor Clojure either.
a lot of people are also sold on shadow-cljs these days because of the Node ecosystem integration
From my perspective, you get what you pay for. Steeper learning curve for Clojure, but much bigger wins.
I think that the value proposition of Angular vs. ClojureScript is very different. one is an application framework, the other is a language
choosing Angular makes decisions for you right out of the gate. there is lots of value in that
But the Angular is also a language, too, because you must use TS (and their way of using it)
Reagent + Re-frame is conceptually very similar to Redux, and has a lot of the same value propositions
so you’re going to run into the same conversation of reagent + re-frame as you would suggesting React + Redux. but you’re also suggesting a new language
The complaint my colleague has is "oh, the repo for this router (bidi) hasn't been updated in 4 years" or such-and-such tool
Our boss sees all the value of using ClojureScript, but we all agree that forcing our colleague won't work, either.
another plus to cljs that is underestimated: it’s fun. developer engagement is hard to maintain and incredibly valuable.
it seems like your senior FE is advocating for adopting a framework/platform to get off the ground fast, whereas CLJS + reagent + re-frame is going to require a lot more of your devtime spent on many things Angular already has answers for. you trade speed for opening up your possible architectures
(side note: i DO wish clojure people would just bump their major version #s to 1.x if the thing is stable)
@lilactown You got it, Will. That's it exactly.
My suggestion would be to look for really concrete examples in your existing Angular codebase(s) that could be done "simpler" in clojurescript. I think its very hard to give someone a solution when they don't think they even have a problem.
@benisrood I think it’s important to remember that in the end rational arguments alone will only get you so far
@lloydshark Unfortunately that's not possible. Our legacy FE is in very ancient Ember.JS and it's terrible. Plus, we need to do things entirely differently
@dnolen I agree. I spent the last few months getting collective agreement to our "core values" of how we want to work and what is important, precisely so we could assess tools/tech from the right standpoint
unfortunately some people don't speak up at the right time, like a man, they just keep quiet and promptly ignore that work.
Everything. Whole product redesign from scratch. Think Bobby's talk from the Conj in 2016 on CQRS + Event Sourcing
one of the biggest things that helped sway my team towards adopting clojure was that we could more easily share resources between FE and server-side development
also they were old crufty Java devs and there’s already a lot of material for converting those kinds of folks to Clojure 😉
Erlang a more appropriate choice for our bottom-level (think masses of call switching and tracking) and problem domain.
To me, that's really the true value proposition. A true full-stack language that doesn't suck, has correct concurrency model, is data-oriented, referential transparency, functional, etc etc
I don't care whether we use React or not. Don't give a shit. I care more about the deeper principles and developer experience.
I would maybe look at some of the more fully-featured frameworks for CLJS and try and create a comparison with Angular
One suggestion would be to figure out tooling and workflow. Are you going to use figwheel? The figwheel main rewrite or the older version? Lein or deps.edn. If deps how will you deploy. Will they need cursive and intellij or are you going to get them setup with emacs. Have a couple sample components made and show them how readable it can be
Indecision on which react wrapper to use could be off putting at the beginning if they are considering it
That's a great conversation, I agree rationality does not win colleagues, having the same problems here. There are a lot of things at stake, problem #1 is that the person will feel not productive for a bit, which many peopl do not like
Also tooling, while better now, still cannot, and will ever, compete to JS big projects
open-mind devs would not care of course as long as productivity is not hindered
(side note - tooling is better for browser than for node as many more folks are targeting browser)
Thanks, guys. Sadly does not want to think about anything beyond convenience as "pragmatism".
I don't want to program like that. It's not programming, to me. It's being an API assemblage donkey.
one thing: maybe try to get an internal tool written in cljs. you're pushing for a homerun. but getting a base hit might open up the field for the future
I learned CLJ some years ago after accidentally coming across Simple Made Easy. Watching it, I noticed that in the abstract/philosophical, the points made in the video were more or less universally aligned with good practices in my own domain (service design). Therefore it seemed like I might learn more about my own craft if I learned the same principles in this other craft. Which turned out to be true.
I’ve been advocating CLJ/CLJS at my current job for a while, giving a few presentations and so on. Of course, how the product is being built doesn’t affect me directly. But indirectly, the technical choices made invariably comes back as impacts on the service delivery and end user experience.
It’s really, really hard to argue the logical chain between (for example) mutability and user experience and service quality.
At one point, the dev team was running out of time leading up to a release, so they decided they would have to drop a particular capability for the release. This particular thing was considered important to stakeholders, but on the other hand, the rest of the stuff in the pipeline was hygiene/basics, so it couldn’t be dropped without having no release at all.
I figured I might try my hand at some dev work, so I sat myself down and wrote the thing as a micro service in plain old Clojure. It worked fine, and made the release.
Still, no interest in Clojure. Actually, little interest in exploring new/alternative venues at all. My theory is that is fatigue from dealing with the JS ecosystem, which is constantly and perpetually new in itself.
Also, I’m the wrong person to offer the advice, probably. A designer poking their nose in dev?
I personally find people who gets nervous/scared instead of curious when they first see the lisp syntax. My theory is, this pulls them a bit far from their comfort zone and most people just got scared? Also, where I live, I find many who advertise themselves as developer do relatively little original work. So, introducing something with not as many example codes online (as opposed to js) is quite challenging.
cross posted from #clojure-spec :
I'm using cljs-spec but I have issues with #object
s...:
Call to #'... did not conform to spec:
In: [0 :data :from] val: #object[b 2018-06-11T00:00:00.000+02:00] fails spec: :week.data/from at: [:args :arg-0 :data :from] predicate: vector?
:cljs.spec.alpha/spec #object[cljs.spec.alpha.t_cljs$spec$alpha40486]
:cljs.spec.alpha/value ({:data {:from #object[b 2018-06-11T00:00:00.000+02:00]}})
:cljs.spec.alpha/args ({:data {:from #object[b 2018-06-11T00:00:00.000+02:00]}})
:cljs.spec.alpha/failure :instrument
so, what I try to spec is #object[b 2018-06-11T00:00:00.000+02:00]
.how to spec that from
-field (`#object [b ...]`)?
What does this mean exactly?
-co, --compile-opts edn Options to configure the build, can be an EDN
string or system-dependent path-separated list of
EDN files / classpath resources. Options will be
merged left to right.
How do I use multiple -co
edn files?
“system-dependent path-separated list” typically means ;-delimited on windows and :-delimited on *nix
so -co foo/bar:be/bop
is what I would expect
Ah, thanks, @alexmiller! :)
I think I may have found a bug.
Trying to run a cljs.main
repl with :modules
results in brepl_deps.js
being clojure.lang.LazySeq
.
clj -A:cljs -co '{:modules {:cljs-base {:output-to "out/base.js"}}}'
Hey, does anyone know how to deploy shadow-cljs
app on heroku
? It’s giving me hard time with java not found
errors. I’m wondering if there’s a simpler path to it than switching to lein-ish project.clj
…?
are you using :target :node-script
? if so you specify :output-to "thing.js"
and then probably just need to add "main":"path/to/thing.js"
in your package.json
Thank you @thheller, I’ll figure it out with :target :node-script
first and then we’ll see
does anybody have an :exclusions
example for excluding core.async so that andare
(bootstrapped core.async) can be used in deps.edn
?
i.e., I'm trying to use cljs-http
and it pulls in the wrong core.async
(need to replace it w/ andare
)
cljs-http {:mvn/version "0.1.45"
:exclusions [org.clojure/core.async]}
^^ seems to have done the trickdoes anyone know the initial reason that Om/Reagent/etc. implemented async rendering?
like I get that it makes some things quite nice, but am wondering if it’s a fundamental requirement to use other things like CLJS like core.async