Fork me on GitHub

I also had problem with Firebase. For me it seems that the problem was that packager didn’t include firebase (at least that is what I think)


@adamfrey: I got this from my boot-react-native template, might help?

(set! js/React (js/require "react-native/Libraries/react-native/react-native.js"))
(defonce react (js/require "react-native/Libraries/react-native/react-native.js"))


@seantempesta nothing I can think of re-natal does which could affect web sockets. Figwheel hot loading goes via a websocket. Well you could try running your code without figwheel lein prod-build and if that works it would mean that figwheel-bridge.js of re-natal has something to do with it.


@seantempesta @drapanjanas I’m using websockets successfully on a re-natal app


@vikeri: yeah I got passed that problem, thanks!


@drapanjanas: I found it! It’s in the figwheel-bridge.js function fakeLocalStorageAndDocument(). From as far as I’ve traced down, creating the fake windows.document variable is somehow causing Firebase to not create websockets correctly. Maybe it’s because the Websocket polyfill only runs if document isn’t present? Anyway, all I need to do now is patch up figwheel to reference the document and I should be good.


@cldwalker: Oh yeah? But not Firebase?


@drapanjanas: Okay, so if I just replace these lines in figwheel-bridge.js:

// This is needed because of RN packager
                // seriously React packager? why.
                var googreq = goog.require;
with this line:
everything works. The above lines look like a workaround due to react’s packager? Is it still necessary?


Because the goog.require function needs a DOM to create a script element to then load the file. Doesn’t really make sense to do this when there’s no DOM, right?


@seantempesta: Yep, packager scans for all occurrences of require(*) and it also matches goog.require(*) that is why direct goog.require('figwheel.connect’) does not work. But, with shimmed stuff goog.require should call importJs function instead of creating script element. Working goog.require is still essential to make cljs code compiled with :optimizations :none work, figwheel need that. You are right we can call: importJs('figwheel/connect.js’), but it is interesting how this causes problem with Firebase...


@drapanjanas: Yeah, I’ve realized you have to shim the require calls. I can’t tell what’s going on in the Firebase code because it’s clousure compiled.


So the localstorage and document faking is just for figwheel right?


I think it might be creating the fake js/document that’s causing Firebase to not work.


I patched figwheel to check for the presense of js/document before using it and Firebase now works.


Yes, I think DOM stuff must be there to make goog.* stuff work


So, I can work again, but I feel like I should do something with this knowledge. Someone else might run into something similar in the future, right? But the patches really need to be submitted to Figwheel, right?


Yes, many things in figwheel-bridge.js are done to overcome either some issues with goog.* or figwheel


Okay, I’ll put together a patch for figwheel and will submit a pull request. With a little luck you could then remove the fakeLocalStorageAndDocument function entirely. I feel like that’s bound to cause problems at some point down the road.


@drapanjanas: Does the figwheel head’s up display work at all? It uses the DOM, right?


@seantempesta: Sorry, late to the party. With ktoa I’ve re-implemented figwheel-react-native bridge with CLJS and removed all the extra code which is not needed. Basically there all the code which is required and no fakeLocalStorage or something like that needed.


@artemyarulin: How does figwheel work then?


I mean, the calls to localstorage and document are still present in the figwheel code.


@seantempesta: Well, I’m using different approach. In figwheel source:

(defn get-websocket-imp []
    (utils/html-env?) (aget js/window "WebSocket")
    (utils/node-env?) (try (js/require "ws")
                           (catch js/Error e
    :else nil))
(defn html-env? [] (goog/inHtmlDocument_))
Meaning Figwheel will use Browser WS implementation and in order to make it happen figwheel-react-native creates all those window.document and so on (actually cannot find how window.WebSocker got created in figwheel-react-native, dunno...), which in turn will make thinking Figwheel that it’s in a browser environment, while RN actually more close to NodeJS, although require ‘ws’ wouldn’t work with RN, unless we hack it like that:
;; Let's tell figwheel to get WS lib from the right place
(when (re-find #"figwheel.client.socket.js" url)
  (aset (aget js/figwheel "client" "socket") "get_websocket_imp" (fn[](js/require "WebSocket"))))
After that everything works like it should be. Figwheel don’t see document/window, meaning it will behave like under NodeJS environment, while RN implementation of WS would be used


@artemyarulin: Oh I see! Very clever.


I’ve implemented this 2 month ago, and don’t remember all the details of the original figwheel-react-native, have no clue where it gets WebSocket from the window, unless RN set’s it by itself. In this case I can drop like 50% of the code...


does anyone know how the react packager works with images? They document it here:, but I can’t require an image even in a vanilla js react-native app


I have my images in a directory called img which is in the same directory as and I’m requiring an image with requre('./img/check.png’), but packager complains that it is an unknown module


I got images working for the vanilla app, now I’ll try it in a cljs app


@adamfrey: I’m looking at how re-natal does it, and it just looks like the just have react’s package manager consume this



it looks like the problem is with boot-react-native, because I can require an image with the regular packager running. @mjmeintjes do you know if boot-react-native can handle requiring images? or is that something that needs to be handled?