Fork me on GitHub
#shadow-cljs
<
2019-10-18
>
emccue00:10:49

and shadow/repl was the ticket

emccue00:10:10

this one seems like it is an actual error and not just me being stupid

emccue00:10:51

this file is some bonkers js

emccue00:10:54

if it even is js

lilactown04:10:56

that looks like Flow or TS

lilactown04:10:02

@emccue ☝️ it looks like it’s expected to be used with the react-native bundler

lilactown04:10:05

seems like bad form

gibb05:10:34

@ghaskins How are you finding the grpc-web development experience so far?

thheller08:10:13

@emccue I added a new :js-provider recently which may become handy for this. basically you set :js-options {:js-provider :external :external-index "foo/index.js"}}

thheller08:10:29

that creates a foo/index.js with all JS requires used in the build

thheller08:10:57

the intent is that you build foo/index.js with whatever external tool you prefer (so in your case react-native metro, but could be webpack, parcel, etc)

thheller08:10:12

you then include that output file completely separately in the HTML

thheller08:10:21

just needs to be included before the shadow-cljs output

thheller08:10:36

and the generated file will make the JS deps available to the CLJS output

thheller08:10:56

basically just an automated way for the webpack setup described in the official docs

danielneal12:10:34

I’m using this lib and struggling to get the right incantation to refer some of its components https://github.com/kmagiera/react-native-reanimated

danielneal12:10:50

I have this

["react-native-reanimated"
    :default Animated
    :refer
    [Easing
     Easing.inOut
     Easing.ease
     Transition
     Transition.Together
     Transition.Change
     Transition.Sequence
     
     Transition.Out
     Transitioning
     Transitioning.View]]

danielneal12:10:05

so far, and I’m trying to use a component called Animated.View which is in the default export (Animated)

danielneal12:10:12

I think the . is causing some problems

danielneal12:10:26

I get the error

152 |     [Animated.View {:style (merge (s [:absolute-fill :bg-ui0])
------------^-------------------------------------------------------------------
 Use of undeclared Var buoyancy.entry-point/Animated

danielneal12:10:39

I can workaround by doing (def animated-view (.-View Animated))

danielneal12:10:46

but I was wondering if there was a more elegant way

thheller13:10:26

@danieleneal hmm yeah that isn't very elegant. the . isn :refer is also kind of problematic

thheller13:10:21

I could change the default resolve rules to also account for :default as it does with :as but the handling of . is already quite bad and even worse in normal CLJS

danielneal14:10:31

js libraries always manage to find some way to be different

thheller14:10:56

indeed 😛

thheller14:10:14

but the . interop in CLJS is a bit undefined

thheller14:10:22

IMHO Animated.View should just work and I might add a change that enables that

thheller14:10:47

just need to think about what might possibly break in the process 😛

danielneal14:10:31

ah that would be awesome but can appreciate it might be gnarly. I’ll stick with my workaround for now

ghaskins15:10:41

@thheller after playing with react-native a bit, im curious as to your insights into what role Metro plays when you have a tool like shadow-cljs in front of it

ghaskins15:10:22

is it largely unnecessary such that we could evolve the react-native flow to consume shadow output directly?

thheller15:10:30

metro is in front of it, it is the final bundler

ghaskins15:10:33

or does it still perform some important functoion

ghaskins15:10:47

understood...it just seems largely redundant

thheller15:10:00

yes, it would be if they followed any kind of standard in packaging

thheller15:10:28

unfortunately they decided that it is ok to use non-standard JS (Flow mostly) in their packages

thheller15:10:51

therefore shadow-cljs can't process it unless I add support for JS and all other kinds of non standard stuff they decided to add

ghaskins15:10:59

I wasnt sure if it was injecting hooks, etc, into the final bundle, or whether it was just re-optimizing the already optimized shadow output

thheller15:10:21

shadow-cljs basically just produces one file that metro is going to include like any other .js file

ghaskins15:10:41

got it, so they are infusing other stuff

ghaskins15:10:04

i figured that was the case, but wasnt sure

thheller15:10:29

yeah they provide the require results (so all JS dependencies, shadow-cljs doesn't process any of them for rn)

thheller15:10:59

they also re-optimize a bit since we can't tell them that isn't necessary

thheller15:10:20

I don't know why they thought they needed to invent their own bundler for this

thheller15:10:11

or rather why they thought it was a good idea to follow no standards at all 😛

ghaskins15:10:19

yeah, me either..though im sure they are not thinking about non-js workflows either

thheller15:10:00

well the write-your-own-bundler is ok .. that is what shadow-cljs does after all

thheller15:10:13

the non-standard stuff is the problem. otherwise shadow-cljs or webpack would just work as alternatives

ghaskins15:10:38

right..im sure it made sense at some level if you are looking at providing turnkey support for pulling in a bunch of human edited js/jsx

ghaskins15:10:08

but for consuming compiler output from something like shadow-cljs, it makes less sense

ghaskins15:10:03

but yeah, im surprised they didnt just reuse webpack or something

thheller15:10:37

there is https://github.com/callstack/haul which replaces metro entirely I think

thheller15:10:09

so in theory it is possible to now use the default tools at all

thheller15:10:55

but it is probably best to stick to the "official" stuff

ghaskins16:10:38

yeah, i agree with that sentiment...at least until one has an understanding when the rules may be bent/broken

ghaskins16:10:50

which I do not yet possess