This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-24
Channels
- # adventofcode (11)
- # architecture (12)
- # beginners (132)
- # boot (19)
- # cider (26)
- # clojure (69)
- # clojure-dusseldorf (4)
- # clojure-gamedev (1)
- # clojure-italy (46)
- # clojure-nl (4)
- # clojure-serbia (1)
- # clojure-switzerland (2)
- # clojure-uk (91)
- # clojurescript (79)
- # css (4)
- # cursive (2)
- # datomic (16)
- # docs (9)
- # duct (20)
- # editors (94)
- # fulcro (15)
- # graphql (2)
- # hoplon (1)
- # instaparse (7)
- # jobs (3)
- # lein-figwheel (3)
- # leiningen (2)
- # lumo (40)
- # mount (35)
- # off-topic (19)
- # reagent (18)
- # reitit (1)
- # shadow-cljs (123)
- # specter (7)
- # sql (5)
- # test-check (4)
- # tools-deps (38)
- # vim (20)
- # yada (9)
@wilkerlucio style question. which would you prefer?
{:something 1
:chrome/options {:matches [""]
:run-at "document_idle"}}
{:chrome/matches [""]
:chrome/run-at "document_idle"
:something 1}
or I guess I could as anyone. I'm sort of undecided on which style to use. lots of nested maps or namespaced keys. Other potential candidates :compiler-options
, :js-options
etc.
I am always for namespaced keys make stuff way easier and then you can spec it
I prefer it for maybe one or two keys with the same ns. after that I prefer a nested map.
ah I just found an issue related to this https://github.com/thheller/shadow-cljs/issues/273
@timovanderkamp do you use emacs+cider as well or standalone?
Yes I do
I run into this issue as well with shadow 2.3.23, without emacs but with cider/cider-nrepl
I'm hitting this error
browser.cljs:39 Uncaught TypeError: Cannot read property 'written' of undefined
useing
shadow-cljs.edn cli version: 2.3.23 node: v9.6.1
tried deleteing target
, this is a website I did few months back, and I updated shadow-cljs, and now can't see my changes
stacktrace
browser.cljs:39 Uncaught TypeError: Cannot read property 'written' of undefined
at Object.shadow$cljs$devtools$client$browser$goog_is_loaded_QMARK_ [as goog_is_loaded_QMARK_] (browser.cljs:39)
at shadow$cljs$devtools$client$browser$src_is_loaded_QMARK_ (browser.cljs:48)
at Function.G__35120__1 [as cljs$core$IFn$_invoke$arity$1] (core.cljs:4222)
at cljs.core.filter.cljs$core$IFn$_invoke$arity$2 (core.cljs:5124)
at cljs.core.LazySeq.sval (core.cljs:3394)
at cljs.core.LazySeq.cljs$core$ISeqable$_seq$arity$1 (core.cljs:3452)
at Object.cljs$core$seq [as seq] (core.cljs:1210)
at Function.cljs.core.seq_reduce.cljs$core$IFn$_invoke$arity$3 (core.cljs:2445)
at cljs.core.LazySeq.cljs$core$IReduce$_reduce$arity$3 (core.cljs:3458)
at Function.cljs.core.reduce.cljs$core$IFn$_invoke$arity$3 (core.cljs:2517)
@thheller I tend to prefer flat maps over nested ones, I found they usually simpler to deal with (only have to know one key instead of a path), so I like the one with namespaces better
I'm trying to get om/brutha working with React. With both react@15 and react@16, I'm getting TypeError: React.DOM.p is undefined
. I'm using shadow-cljsjs.
I'm trying to get play-cljs (https://github.com/oakes/play-cljs) working with shadow-cljs. It seems it bundles its own JavaScript source in their code (rather than using an external dependency) for the library p5.js, and then require it with:
(:require [goog.events :as events]
[p5.core]
[p5.tiled-map]
...
When I try to compile this with shadow-cljs I get
The required namespace "p5.core" is not available, it was required by "play_cljs/core.cljs".
Is there a way to make this work?
(edit: I have already installed p5 in my project with npm)@jjttjj someone successfully used play-cljs
with shadow-cljs but I forgot how exactly. typically you'll just need to install p5
via npm
and create a shim file ala https://shadow-cljs.github.io/docs/UsersGuide.html#cljsjs
@escherize can you share your p5/play-cljs setup?
Rather fundamental question of how to use npm-libs with shadow-cljs. I can import them properly, but I fail to get this to work: https://react-bootstrap-table.github.io/react-bootstrap-table2/docs/getting-started.html#your-first-table More specifically, how translate this line to cljs:
export default () =>
<BootstrapTable keyField='id' data={ products } columns={ columns } />
I can't seem to use [:> BootstrapTable {:data (clj->js content) :keyField "id"}]]
or [BootstrapTable {:data (clj->js content) :keyField "id"}]]
reason: Cannot call a class as a function
I've got this require: ["react-bootstrap-table-next" :default BootstrapTable]
hmmm... missing something. not sure what yet.
d'you mind sharing the cljs code? (how d'you use BootstrapTable
?
that code snippet is basically complete. the only thing missing is
(defn start []
(js/console.log "Starting...")
(r/render [app]
(.getElementById js/document "app")))
(defn ^:export init []
(start))
naa, that part is ok.
I'm struggling with the table.
i mean you literally have a code complete example. i just cloned reagent-shadow-cljs-starter, did a yarn add, and bam it works
nope, I didn't...
let me try 😛
@kurt-o-sys which version are you using? there was a bug in the closure compiler that was fixed only recently. https://github.com/google/closure-compiler/issues/2822
version of? cljs?
[thheller/shadow-cljs "2.3.21"] [org.clojure/clojurescript "1.10.238" :scope "provided"]
(well, shadow-cljs, but with :lein true)
oh, wait.
can you run lein deps :tree
and see which com.google.javascript/closure-compiler-unshaded
version you get?
[com.google.javascript/closure-compiler-unshaded "v20180319"]
but I may be getting there.
May be related to the table being loaded twice (for some reason), first time with empty data.
ok, will check.
ok, thx...
not sure why you are getting the old version though since the shadow-cljs version you have already depends on the newer on
updated the shadow-cljs version to 2.3.23 now.
which gives me the new version of the closure-compiler.
yeah, upgrading seems to help! thx a lot!!
Does anyone know if it is possible to define deps on a per-build basis in shadow-cljs.edn
?
@nick828 hi! no that is not possible as its typically not useful to do this for CLJS. it is perfectly fine to always have devcards on the classpath as your build config defines what ends up in your build. not the classpath.
ah ok, so let’s say I wanted to ‘accidentally’ add devcards to my :app
bundle… What would I have to do?
your namespaces decide what ends up in a build. so if none of your namespaces requires devcards.core
then it will not be included.
cool, thought so - but I just wanted to double check. I’m much more familiar with JS than cljs and I think this is analogous to tree-shaking
not really. tree shaking also only optimizes the code you actually use. you could have thousands of npm
packages installed but it would not matter to your build unless you require
them all
Just out of interest could you point to an example of how this might look? I’m using deps.edn to define those aliases in the screenshot above
no need to use shadow-cljs
directly. clj
works just fine too. just a tiny bit more to type out
Thanks Thomas 🙂 I’m really enjoying using Shadow-cljs as a front-end dev it’s far better than the alternatives I’ve been exposed to in the cljs eco-system
new 'translation' question: https://react-bootstrap-table.github.io/react-bootstrap-table2/docs/filter-props.html#how-to-use
(ns ...
(:require
["react-bootstrap-table-next" :default BootstrapTable]
["react-bootstrap-table2-filter" :refer [textFilter] :default filterFactory]))
(defn generate-columns [fields]
(map (fn [[fieldname title props]]
(merge {:dataField fieldname
:text title}
props)) fields))
(let [
columns (generate-columns
[["name" (i18n [:general/name]) {...
:filter (textFilter) )}]
["email" (i18n [:general/email]) {...}]])]
[:div [:> BootstrapTable {:data ...
:keyField "id"
:filterFactory (filterFactory)
:columns columns}]]))
shows the filter, properties to set work fine, but when I start to type (and hence, the filter should start):
text.js:102 Uncaught TypeError: c.props.onFilter is not a function
at text.js:102
seems easier to just
(def columns
(-> [{:dataField "id"
:text "Product ID"}
{:dataField "name"
:text "Product Name"
:filter (textFilter)}
{:dataField "price"
:text "Product Price"
:filter (textFilter)}]
(clj->js)))
oh, to generate the columns more easily.
there's always that datafield and text, so I just provide them as vectors.
depends on how many fields you have and how many tables 😛
yeah, trying with clj->js
oh, ok...
so you are probably passing a CLJS vector to the react component which expects a JS array
@kurt-o-sys the syntax is :filter (filterFactory)
not :filterFactory (filterFactory)
oh sh*t.
must be getting late... need to get some sleep.
thx a lot again! (I love shadow-cljs, I love the community, ... I'm full of love this evening :p)
how i miss the amazing error checking of libraries like react-dnd, which would have caught that and given you nice error message. a really good and easy to use map validator would save the world so much grief. i had high hopes for schema and spec but they’re not quite there.
well, I could've caught that there was a 'wrong' key.
I mean, generally, I wish this existed. I had high hopes for a lisp-based language having good tools in this department, which is one of the reasons why I got excited about cljs. Actually in JS, if you have typescript or flowtype going, these problems get caught at compile time. It’s not there yet, but it could be some day. 🙂 Still the best error checking seems to come from the facebook people who have a bunch of ad hoc checking built in.
again: this assumes that the JS component is written in flow or typescript. if its not you gain nothing.
and the propTypes checks are done by react anyways so the JS components could add them easily
well with flowtype third parties can type it. there’s a sideband project to provide types for libraries
for example, you should be able to type the shadow-cljs.edn such that if you misplace a key like :after-load
, it should be able to give you a super high quality error message
(s/def ::y (map-spec :req {:foo string?} :closed? true))
(s/explain ::y {:foo "1" :x 1})
extending spec is definitely possible but a bit cumbersome due to the macro-heavy implementation
so definitely not recommended and I generally agree with the design decision done by spec regarding open maps
@bhauman also did some impressive stuff in figwheel regarding the config validation, which could probably be turned into a really good library given unlimited time 😉
@wilkerlucio I'm beginning to question the viability of my :chrome-extension
support. I extended it to support other scenarios like page/browser actions and it all works ok enough but has some drawbacks. might just end up recommending using a separate build for the extreme edge cases
yeah, I think the current support is good already, I don't mind having multiple builds for (I already do with the devtool), I think its to contemplate the main cases, and leave the rest out
the main issue IMO is the leak of repl support between builds, but that's not a specific problem of chrome target I guess (more related to modules in general)