what are you looking for in a testing library?

A testing library that lets me test user interaction with the app. I'm using the react-testing-library, which integrates with jest and jsdom. But not being able to install jest and that jsdom works with node.js only, I'm looking for alternatives. Jest api's for checking which components are visible are pretty neat:

expect(screen.getByRole('heading')).toHaveTextContent('hello there')

the haveTextContent functionality is what I aim to use 80% of the time from jest.

So long as a small script can recreate this function, I won't need jest for the most part.

some utility libraries (I think medley?) have an mapply that does this. Or you can do (apply foo (mapcat identity m))

that worked out fine, thanks

"react-content-loader": "^4.2.1",

import ContentLoader from 'react-content-loader';
window.ContentLoader = ContentLoader;

[:> js/ContentLoader args]

(require [react-content-loader])

(let [content-loader (.-default react-content-loader)]
  [:> content-loader args])

[:> react-content-loader args]

Was going to post more cases, but realized they were the same

Got a bunch of source map errors, they may be due to other errors in my setup, but posting here in case they ring a bell. These examples are 2 of many (tens or hundreds)

DevTools failed to parse SourceMap: webpack:///node_modules/react-draggable/dist/react-draggable.js.map

DevTools failed to parse SourceMap: 

the sourcemap stuff doesn't yet seem ClojureScript related will need more information

the default thing is known and will be addressed soon like in a couple of week but not in the pending release which is just about fixing the immediate small issues w/ the last release

https://clojure.atlassian.net/browse/CLJS-3235

is the ticket if you want to follow along

Ok, thanks! Nothing more to report for now, then.

JS truly is the Comic Sans of langauges.

Gotcha. I’m communicating with WASM. I’ll just have to state the intention separately and coerce it to the proper format when the WASM receives it.

Just spotted that 597 had a fix for foreign libs & externs

You can check out how I do it here with fighweel https://github.com/johnmn3/tau.alpha

There's a lot of changes coming with the :bundle stuff though, so it'll probably need some tweaking for that sitch

Thanks!

wow cool! Do you have a config that allows integrated REPL development aka through CIDER?

first of all I think this is fantastic but I'm also curious if this will apply to service workers ... slightly different API than web workers: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

same issues essentially but no idea if they use a sharedarraybuffer or not between them and main thread

Haven't used cider in years... Does it use figwheel? If so you might be able to use whats in that project.

Yeah, the code in there might not work in the service worker. But the mechanism of connecting back to the repl might be similar

I've definitely repled from a service worker before

Many years ago when I was exploring them

awesome... I think this will help a lot 🙂 I'll let you know what I come up with, thanks for fighting the good fight on this

No prob! Oh, sharedarraybuffers? those should be orthogonal concerns.

Are you trying use SABs?

really my issue is maintaining a persistent repl connection to serviceworkers

since the serviceworker is not started by the main thread necessarily (it has a bit of a life of its own), it's a little tricky

I'm not sure how to force the service worker to open a websocket to figwheel

Right, with figwheel.main, it's a little more straightforward since you can just include figwheel.repl and then connect to the server. Pretty easy.

ah that's not a bad idea. you mean embed a repl in the client code?

Nah

oh lol

Just that figwheel.repl has the necessary machinary to connect back to figwheel server

right so you would include (require 'figwheel.repl) in serviceworker.cljs? or am I misunderstanding?

right

and then it's something like repl/connect url-string

gotcha. Yeah that's a really good idea

It's in tau.alpha

awesome. There are SO many moving parts its hard to keep track of

You have to disable config validation figwheel, which you can see in the example project in tau.alpha

It is, I agree

oh man I can't even imagine how long it took to figure that out... and the chrome flag for sharedarraybuffers

that's partly why I haven't switched to shadow-cljs. took me so long to figure out how to use figwheel-main I'm just sticking with it until I have a compelling reason to switch

everyone says it's the bees knees but my brain is only so big

You don't need SABs for any of this though

same here lol

I'm not sure what a SABs is 😅

ohhh

sharedarraybuffers

aye lol s18

(I thought that was pivotal for switching repl between main thread and workers but maybe I read docs wrong)

Where did you read that?

https://github.com/johnmn3/tau.alpha#tau

my brain summarized that as "need SABs for tauons"

Ah yeah, for tau.alpha...

in that particular implementation, a tauon is basically a webworker, with some extra semantics wrapped around it

You can think of tauons and webworkers as somewhat synonymous

Tauons add more semantics to act more like threads in an executor pool though

Then you have a tau, which is like an atom

and that atom is backed by a SAB

things are serialized to and from it

sorry I'm a bit confused only because you mentioned alpha like its a separate thing, is there a different repo?

"Ah yeah, for tau.alpha..."

is there a regular "tau" or something?

The library, tau.alpha, is kinda named after the primary shared-atom thing called a tau

I like it 😄

ohhhh I see

ok ok, I'm caught up

So, a shared-atom (a tau) is backed by SABs, and data is serialized to and from it

you didn't realize I was talking about the need for SABs in reference to tau.alpha, you thought I meant in reference to figwheel

you can actually use that channel for communication between workers, if you want

Right

😅 if I can't even communicate with humans I'm not sure how much luck I'll have with serviceworkers but you never know

hopefully they are equally patient

But primarily it's a shared container for data structures, rather than a comms channel

lol

I think it's a really fascinating approach. It's too bad we don't have journals or anything to write to, it's worthy of a write up

yeah

fwiw, I'm thinking about scrapping the whole tau naming thing... The architecture there kinda straddles a world where shared-atoms can either be abstractions that serialize and synchronize state between atoms via postMessage. Vs a world where you can just use SABs. So I'm thinking about making a fresh lib that focuses specifically on SABs.

@U050PJ2EU do you have any insight into when SABs will be widely available again? https://caniuse.com/#feat=sharedarraybuffer

Yeah, unfortunately you're going to have to get fancy with some headers https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes

but probably in a few months

@U050PJ2EU I might consider making something that has the same API but you could swap out underlying configurations between SABs and syncronized atoms via msg

or whatever other abstraction

@U3BALC2HH probably a good idea

I haven't looked...but do you happen to know about support in more controlled environments like Cordova and Electron?

you could checkout some of the architecture #datahike uses to encourage pluggable back ends. I'm not trying to scope creep you here but I think it's a very cool concept and I would just hate to see some folks not adopt it b/c they have concerns about the underlying implmentation

Cordorva... I think tries to have many js vm targets. Electron always targets V8, so it should have the same functionality, after the updates roll in.

it solves a very generic problem

also that way when they fix the spectre situation your users can just flip a config value and get the benefits of SABs w/o having to change any code

but what do I know ¯\(ツ)/¯

I don't have a great track record with anyone adopting my tools sooo

take my opinion with a grain of salt

It's a good idea. The pieces of tau should be busted out into libs, especially now that the project has spread out a little more

nod. Here's something to keep an eye on too... so service workers, I'm not sure if you're familiar with them, are like web workers but more persistent and with network proxy abilities. So serviceworkers + webRTC + tauons == really slick peer 2 peer information exchange and data sync

it's an area that I'm actively researching 🙂

Yeah, service workers are interesting

Before SABs, I used them to make a hack to simulate blocking semantics, to enable future/await

Cause you could do a blocking xhr call and then use the service worker to hang the call and return when you want to wake the worker up.

They're interesting for proxy stuff. Or maybe doing SSR, client side 😆

HAHA yesss!!!

I was wondering what the possibility of moving the react diffing stuff to a service worker would be

But ultimately, I think you could probably get most of that done in regular workers

As long as you don't do any computation heavy stuff on the worker, and only use it for routing and proxying

I considered some kind of complex scheme with two datascript conns, one in the main thread and one in the service worker, and the one in the worker would be the one you "write" to (like a transactor) and the one in the main thread would be the one you read from (like a peer) and this would give you fine grained control on when and what data reaches the main thread. That way you could throttle the datom flow to ensure 60fps paint cycles

but ultimately it always paid to just write less shitty, less complicated main thread code than put that crazy scheme together

have you seen the example on tau.alpha? https://johnmn3.github.io/tau.alpha/

that's basically how it's done

Your bottleneck is on serialization to and from the SAB

so we need to rebuild datastructures on top of typed arrays so they can live in SABs transparently

ahhhhh interesting. I wasn't sure how much the bottleneck would be. Does it bottleneck throughput, choke on serialization, or mostly just volume of data that is the biggest issue?

i.e., would it be more efficient to transmit a million words in seperate messages or a million words in one big message?

Try not to think about "transmit" anymore

:rolling_on_the_floor_laughing: yeah with covid it's a bad idea

Your writing to a place that both the main thread and the workers can see at the same time

lol

I was thinking from the traditional onMessage perspective, not SABs

That's the old way 🙂

But in the example above, there is no serialization

Because we're operating on binary data, in cljs

so it's fast

We're not serializing CLJS persistent datastructures in that example

So, either way, via onMessage or via sabs, you'll have to serialize

The benefits of sabs though... If your data is already well typed, it can live in both places at once, because it's literally shared memory.

If you have it living in the SAB

Oh yeah I have no doubts. Will be interested to see how you handled mutexes there

seems like race-condition city!

Here's a sneak peak I made of trying to make a memory pool for SABs, to start building shared persistent data structures on top of https://twitter.com/Doxosophoi/status/1236337446729719810

Yeah @U050PJ2EU this is really fascinating stuff. I hope they fix the speculative execution vulnerability soon because there are so many great applications for this.

I'll certainly be watching the project!

Yup! Once you have a working, good lock-free mem pool on top of sabs, with weak references for managing clean up, we should be able to build a datascript like thing on it and do exactly what you described.

What I think is most fascinating is, down the road, as latencies continue to drop, actually reimplementing the SAB interface, so that workers can attach to SABs via network. Then you could do some really interesting distributed systems stuff with just that abstraction.

Like, if you're in a datacenter and can ensure low latency data access between a few million workers

Good to know - thanks for the tip!.

I haven't used that before, but in general clj and clojure commands read your deps.ednfile to determine what dependencies your project has, and lein commands read your project.clj file, and neither command will read the file of the other.