https://clojureverse.org/t/shadow-lazy-convenience-wrapper-for-shadow-loader-cljs-loader/3841

I am on 2.8.10 has somebody started seeing the following?

[:az] Build failure:
The required JS dependency "bufferutil" is not available, it was required by "node_modules/ws/lib/BufferUtil.js".

Searched in:/home/arichiardi/git/laputa/scrutinize-fn/node_modules

You probably need to run:
  npm install bufferutil

See: 

and

You probably need to run:
  npm install utf-8-validate

if thats a dev build intended as a one-file output you probably want to :keep-as-require #{"ws"}

no clue what those packages are

so is the one-file feature causing that? because it looks like those are required by ws

not really

it does try to require them ... but has a fallback and seems to work without?

try {
  const bufferUtil = require('bufferutil');
  const bu = bufferUtil.BufferUtil || bufferUtil;

  module.exports = {
    mask(source, mask, output, offset, length) {
      if (length < 48) _mask(source, mask, output, offset, length);
      else bu.mask(source, mask, output, offset, length);
    },
    unmask(buffer, mask) {
      if (buffer.length < 32) _unmask(buffer, mask);
      else bu.unmask(buffer, mask);
    },
    concat
  };
} catch (e) /* istanbul ignore next */ {
  module.exports = { concat, mask: _mask, unmask: _unmask };
}

uhm ok let me try to uninstall and try :keep-as-require #{"ws"}

but unless you are using ws in your release build you can safely ignore that

or just :devtools {:enabled false}

got it...I have one final question

I still have a problem with one internal lib that Gcc cannot transpile

scoping the settings to :release {:js-options {:js-provider :shadow}} would also be best probably

no point in single file for dev really

yeah you're right

does :output-feature-set support :no-transpile?

:output-feature-set :es-next will basically keep everything as is

:no-transpile never worked

if you use a feature the GCC doesn't support and can't parse no setting will save you

Ok cool I have tried :es8 will try that next

if it fails to parse it can't work since we need to process it

Yeah I kind of guessed that ..weird is that this module comes from a TypeScript project that in theory compiles to es6

whats the error? closure has some known issues with some ES6 code I think

Still the one I posted on the issue let me fetch that

> Closure compilation failed with 2 errors > --- node_modules/...dist/execution/hydration.js:48 > This code cannot be converted from ES6. Undecomposable expression: Please rewrite the yield or await as a separate statement.

try bumping the closure compiler to [com.google.javascript/closure-compiler-unshaded "v20190215"]

they changed something regarding that I think

didn't test that release yet

ah doh

https://github.com/google/closure-compiler/commit/640fd3f705dd5f015278abfd756b6a793ceecc73

it isn't in the release yet

but doesn't the language setting take care of this?

I am trying things ...

need minimum :es8 to keep generators/async/await as is

I'll try (meeting now)

tried many combinations of the language settings and it seems none worked, I will probably need to wait for the next release of GCC

has someone experienced

bidi.js:276 Uncaught SyntaxError: Invalid regular expression: /[Ö‘-Û¯Ûº-ࣿâ€�-��-�ï¬-ï·¿ï¹°-ﻼ]/: Range out of order in character class
    at new RegExp (<anonymous>)
    at bidi.js:276

also from the shadow-cljs hud, pops an error when I get an error

hud.cljs:301 reload-failed TypeError: r is not a function

@hlolli that is caused by an incorrect charset encoding in your html

add <meta charset="utf-8"> to your HTML

thanks @thheller that fixed the bidi.js error.

the other one probably react/reagent bug introduced after bumping, digging deeper.

that is an error that occured while loading your code. should get it if you just reload the page

probably nothing to do with shadow-cljs

Im getting "r is not a function", and the only stacktrace showing my cljs code is the init react render. Yes that hud error also gone. So all on my side now :=)

ok now I get what's happening, by bumping react-dropzone, the whole spec changed, and instead of using props, it expects a function callback in the child element, don't ever remember seeing such a thing in react.

<Dropzone onDrop={this.onDrop}>
        {({getRootProps, getInputProps, isDragActive}) => {
          return (
            <div
              {...getRootProps()}

function-as-children is a common pattern in React-land

see: Context Consumer components

it's a small webapp Im making, the whole page is a html5 filedrop, I wonder if this function as child patterns causes severe slowdown of the whole webapp, given that the whole app is a child of the filedrop. In which case, I'd just css it to do the same but be a sibling of the rest of the webapp.

but first time I see this, especially as an interface. Thus far, function as child has been mostly a cause of error messages 😛

function-as-children is pretty gross to work with in Reagent (syntax wise). but you shouldn't see a significant slow down

you might find that my wrapper library for React fits your use case better than reagent: https://github.com/Lokeh/hx

it makes using patterns like function-as-children much easier than reagent

it's small enough app that I can test your react wrapper. Bit off topic here, but I do get the classic: react-dom.development.js:507 Warning: Functions are not valid as a React child.

sorry, slack had me on overwrite mode suddenly, (so I typed forever)

does hx work with re-frame?

any react component works with re-frame, so this question falls on itself.

re-frame depends on reagent for it's RAtom and scheduler

so you'll have to include both reagent and hx, and use React-Reagent interop to use hx components in reagent and vice versa

I have a fork of re-frame that removes all of the reagent dependencies, but I'm not ready to publish it as an project I'm willing to support

there is definitely a way to use just re-frame and hx, and include reagent just for it's RAtom implementation, but I haven't tested this

I see, as long as hx just returns a react element, should be fine, inlineing (hx/f may not be pretty within a reagent app. For a small functioning webapp, hx makes sense.

speaking for myself here, as soon as state becomes big and many side effects, re-frame is a headache saver. But pure reagent I use a alot.

you shouldn't have to call hx/f much. using defnc will create react components for you

@thheller so you where saying that :no-transpile in that case above would still try to transpile? there is no way to say "please don't touch this JS"?