Hi all! I’m working on a POC for our company that has me frustrated. Everything I’m doing so far works great, until I try to use these 2 components:

https://github.com/mosch/react-avatar-editor

https://github.com/xiaolin/react-image-gallery

I’ve seen a variety of suggested approaches, from using webpack to :npm-deps, as well as others. Feeding the source for these 2 components into the externs generators online both generate the same error, that the target class I want to export is not found.

Is there a way to tell from reading the component code which approach is best?

So here’s what I discovered. I’m able to view both components only when I use webpack to build them and :foreign-libs to import them. On top of that, the gallery requires I use (.-default image-gallery) to access it. I’d rather use both of these components without the extra layer of webpack. How can this be done?

@jmckitrick I use the "double bundle" approach and have been for a while: https://github.com/pesterhazy/presumably/blob/master/posts/double-bundle.md

it's the pragmatic approach and, most importantly, it's guaranteed to work, because everyone else is using webpack

so if you run into issues, you can be sure that most other users are running into the same problems

granted, it's not philosophically pure, but you can use any npm/react dep you want without worrying

So that’s suggested over this approach, then? https://clojurescript.org/news/2017-07-12-clojurescript-is-not-an-island-integrating-node-modules

If so, I’ll stop wasting time to get it working, and read that article you linked @pesterhazy

full disclosure, I haven't tried the "new style" cljs integration options, because what I have (and have described in the article) just works

I personally would suggest trying that approach and embrace webpack as a secondary build tool

that's not an official recommendation from the core team of cljs though; I know they dislike webpack

also re: externs, I'd suggest using Simple Optimizations to get started

and only switch to Advanced once you have strong business reasons for smaller bundle sizes

I've built entire projects and never gotten around to switching to Advanced because it wasn't a priority

the upside is you bracket the entire host of issues surrounding externs and minification

then treat it as a separate step (and don't let it block your initial progress)

all react libs will just work that way (provided you understand JS interop and Reagent interop well)

ok, I’ll dive in and give it a shot.

simple example here https://github.com/pesterhazy/double-bundle

Ok, I’ve got my POC working with your approach. Excellent!

nice approach @pesterhazy--thanks for sharing. @jmckitrick, by the way, you’re not crazy. for peons like me, the “new style” integration approaches like the one in that article have never worked for me and just wasted a bunch of my time. I’ll add two tips: one, instead of calling goog.object directly, use cljs-oops, which has some development-time debugging built in and is a little bit more ergonomic. second point is that if you don’t like the webpack approach (though honestly if it is working for you, I think it’s a good approach), there is also shadow-cljs, which so far has worked very smoothly for me and has webpack-like module bundling and splitting built in

@pesterhazy Is there any drawback to using aget rather than goog.object/get ?

@lee.justin.m Given that I want to reduce friction with non-cljs members of my team, I’ll stick with webpack 😉

I'd argue that friction will be a gazillion times lower with shadow-cljs 😉

the reality is that aget will work but it is documented explicitly as to be used on arrays in its docstring. they’ve said they want to start adding runtime checks to it to warn when it is misused. reality is too much code abuses it so it’ll probably work always 🙂

i can testify that shadow-cljs is way easier than futzing with webpack but maybe using webpack will be a nice comforting blanket for your team

@thheller How so? I’m intrigued….

Disclaimer: I’ve just started reading about shadow-cljs

well you can consume direclty from npm without any hacks or cljsjs

you can also compile the output in a way so that the final build is done by webpack

the example is very old but should still work https://github.com/minimal-xyz/minimal-shadow-cljs-webpack

@jmckitrick @lee.justin.m https://clojurescript.org/news/2017-07-14-checked-array-access on aget vs the appropriate ways to access object properties

@thheller What is an ‘HMR app’ ?

hot-module-reload from webpack

just a demo. its much worse than just using the built-in reloading for cljs.

just demonstrating how you'd use CLJS inside a JS project

Got it.

yeah shadow-cljs is another option to consider

gobj/get is recommended and aget may cause issues in the future, like @lee.justin.m mentioned

Do you guys have any advice for debugging when a component isn't updating as you think it should? I'm doing something sort of tricky where I'm passing in a completely different atom/cursor to a component to show a different historical state, and in the particular case of HTML input elements, I don't always see the state accurately reflected.

I may be doing something crazy but it's hard to boil it down to a minimal (shareable) example, but I'm also not having a lot of luck figuring out why it's choosing not to update.

@pmooser take a look at this FAQ. However, if that doesn't help, I'd encourage you to try to boil it down as best you can .. difficult to help otherwise.

https://github.com/reagent-project/reagent/blob/master/docs/FAQ/ComponentNotRerendering.md

Thanks. It's none of those things, as far as I can tell, but I'll keep digging and let you guys know when I figure it out.