I am trying to convert some javascript into clojurescript and I am not sure if I am doing it right. I don’t get any errors but I think I might be doing something wrong. I am trying to convert the following as can be found here: https://docs.amplify.aws/lib/auth/start/q/platform/js#re-use-existing-authentication-resource

import Amplify, { Auth } from 'aws-amplify';

Amplify.configure({
    Auth: {
        region: 'XX-XXXX-X',
        userPoolId: 'XX-XXXX-X_abcd1234',
        userPoolWebClientId: 'a1b2c3d4e5f6g7h8i9j0k1l2m3',
    }
});

// You can get the current config object
const currentConfig = Auth.configure();

(defn configure []
  (.configure
    Amplify
    (clj->js {Auth {:region "eu-west-1"
                    :userPoolId "eu-west-1_xxxxxxx"
                    :userPoolWebClientId "xxxxxxxxxxxxx"}}))
  (.configure Auth))

you could create js objects directly

#js {:Auth #js {:region ...}}

in your example above Auth should be :Auth

Oh nice, I wasn’t aware of #js, thank you

hi! Is there a way I could integrate something like this into my re-frame application? https://github.com/elrumordelaluz/reactour This is the code I'd need to "translate":

import React from 'react'
import Tour from 'reactour'

class App extends Component {
  // ...

  render  (
    <>
      { /* other stuff */}
      <Tour
        steps={steps}
        isOpen={this.state.isTourOpen}
        onRequestClose={this.closeTour} />
    </>
  )
}

const steps = [
  {
    selector: '.first-step',
    content: 'This is my first Step',
  },
  // ...
]

I'm trying to get a hold of a map from a parent window ( js/window.opener ). Everything looks fine, except that something weird is happening with the keys:

;; Define the map in the parent window
(when-not js/window.opener
  (def test-map {:a 1}))

;; In the child window, try to get a hold of the map
(when-let [opener js/window.opener]
  (when (not= js/window opener)
    (prn (assoc (into {} (js-get-in js/window.opener ["mynamespace" "test_map"]))
                :a 2))))

{:a 1, :a 2}

Oh, and the into is necessary, otherwise all I see when printing the map is #object[Function]

you’ve loaded this CLJS code in a separate window?

try checking the types of the keys - maybe they both print as :a but aren't equal?

each window is it’s own JS “realm” or context - you cannot share data structures between the two

Yes; I have small application opening a child window opening the same cljs code.

each window will have it’s own version of keyword, map, etc. and they won’t be compatible

IIRC, anyway

like, you have a separate script tag in this window right? that loads all of cljs.core?

Yes

But I'm pretty sure I can share variables between parent/child windows. As for complex datastructure, I don't know.

I can print the list of keys in a map, but they are never equal from one window to the next. 😕

yeah, each window has it’s own version of cljs.core, so they won’t be equal

Hmm... then I wonder if I can simply copy the context from the parent to the child. I'm gonna give it a try.

I think your best bet is to serialize the structures between the two

I bet you could even fix it by walking the hash-map and calling keyword on every keyword

this isn’t just a CLJS problem, it’s a JS thing: https://stackoverflow.com/a/49832343/4379329

Yes there are multiple approaches to share serialized data, but unfortunately I have many identical MBs of data to share.

since the equality / return of keyword is based on interning

this doesn't come up for non-interned types (symbols, strings, hash maps) as they use value equality

I’m surprised that you can even use any data structures shared between the two windows. you’re pretty much relying on undefined behavior

(though you might need something fancier than calling keyword, as that function might short circuit if the type is already keyword, and not catch that it isn't the interned one)

@lilactown it makes sense that it would work - it's two of the same cljs version, so the bytes have identical meaning, until you hit something that's not a value type (keywords)

it doesn’t work like that

lots of things rely on constructor or reference identity, which you don’t share between the two windows

it’s hard to know what will work and what will not without understanding the internals of cljs.core

OK -fair enough

of the "vanilla" data types - the things that work in edn without reader tags - I would expect keywords to be the gotcha, but then again it should be easy to verify what does or doesn't work for a given browser engine

sharing large amounts of data between windows is currently not a greatly supported thing