@habanerao why are you wary? Are you wary of clojurescript, or Om as a react wrapper?

(thinking out loud) webpack is awesome in that it finally blurs the line between "assets" and "code" (there is none in a modern web, IMO). It's interesting if CLJS community can come out with anything better :)

@habanerao IMO having to read raw generated JS is a non issue...with source maps it's not something you really have to do that often, if ever.

That wasn't what he was asking I think. I think he meant can they take the generated JS and move back to javascript+react

and abandon cljs

I'm wondering whether cl-format is ok with advanced optimizations on? Unlike goog.string.format?

@grumplet haven’t heard many experience reports - but it should work

if it doesn’t file a bug report

@dnolen - ok thanks.

Has anyone tried annotating the props/state of their Om components with clojure.spec? I have some shared components and I was thinking it would 1) help enforce their correct usage by different people and 2) enumerate meaningful cases to automatically turn into devcards.

@asolove haven’t had time to pursue this yet but I have some more ambitious thoughts with respect to spec & #om

i.e. queries are specs

@asolove in anycase, yes that’s a great idea

@dnolen oh interesting, like the query idea

yes I think it would be very powerful

validation across client/server - and also we can capture typical user errors immediately

Ok, have you thought about implementation for adding specs for state/props?

Like, not sure if that should be in core om or if I should make a wrapper that inserts checks at all the lifecycle methods

@asolove why do you need that if you have it at the level of queries?

if for some reason you can’t do that - then sure you can wire in spec in yourself

@asolove btw this conversation is probably best to have in the #om channel 🙂

Ah, yeah

Is it (still) true, that cljs files cannot have both a ns declaration and (require ...) expressions in arbitrary places?

@jannis you’re never going to have require in arbitrary places

you can however put them at the top of your file after ns, pretty sure that @anmonteiro checked that this works in the latest releases

@dnolen hrm, actually I'm quite sure that doesn't work

or might be bugs

@anmonteiro ah ok - then there you have it 🙂

it’s not that useful anyway

the constraint is: either ns or a bunch of require's

if we see ns we bail with that info and don't check additional requires

it might work anyway, but it won't count for dependency sorting, which will give you all kinds of warnings or errors

@anmonteiro right I’m fine with it not working

there’s no use case for it

Hmm. I am writing a modular system where I'd like to require some cljs namespaces from other packages at build-time. E.g. the namespaces I want to require are listed in an EDN file in the build-time classpath, lifted into CLJS via a load-edn macro and would then have to be required. I guess that approach won't work. I guess I could generate a cljs file with top-level (require ...) statements for those namespaces and then hard-require that file in the code that does the "loading".

it should also be pretty easy to make it work, in case we want to support it. should only be required to change parse-ns

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L3176

@jannis I don’t not understand why you cannot handle this via a custom macro that expands to ns

that macro can see whatever compile time build options got passed in

Ah, you're right, that is probably the best option!

@jannis note that you probably can't replace ns with that macro

oh, that's not right. you probably can

sorry for the confusion there

I was just thinking... wouldn't I have to require that custom macro first, probably via an ns statement?

@jannis hrm you might need to create this macro in the cljs.user ns for this to work?

Is there documentation on what cljs.user is? Is everything defined in cljs.user available without explicit importing?

@jannis no you’re going to be on your own here

what you’re attempting to do is way beyond anything we explicitly support

Ok 😉 I'm just trying to combine multiple cljs libraries together without knowing exactly which I will be combining upfront - it's decided during build. I can see how this is something best handled outside cljs - e.g. through code generation in the build process.

yes

No problem, I thought I'd double check about require before I do it that way. Thanks, as always 🙂

adzerk/boot-reload has an interesting approach: they don't mess with code generation at all but instead add namespaces to :require in the .cljs.edn file that adzerk/boot-cljs builds the cljs sources from.

@asolove currently, Om Next supports a :validator key at the factory, you can trigger a spec check there, like (om/factory SomeComponent {:validator #(s/valid? ::my-spec %)}), then it will validate on component creation

@wilkerlucio thanks!

@asolove glad it helped, I was doing exactly that, but the problem with this approach is just that it doesn't gets you good error reporting (it just says that it failed), to go around this I made a helper, you might wanna do something similar:

yeah

Can anyone point me to example of how to get a leiningen build to copy a file to another folder. Background we have "dev" & "prod" builds which output to /run/resources/public/compiled_dev | /compiled_compiled_prod respectively, but we'd like the same index.html copied to the respective path.

is there lightweight alternative for timbre in clojurescript

?

I particularly need log/spy, but using timbre for it feels like overkill

ehmm… I think I’m gonna use this: https://github.com/adzerk-oss/cljs-console