This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aatree (3)
- # admin-announcements (14)
- # aws (2)
- # beginners (23)
- # boot (58)
- # braid-chat (15)
- # cider (8)
- # clara (5)
- # cljs-dev (1)
- # cljsrn (38)
- # clojure (82)
- # clojure-china (2)
- # clojure-czech (16)
- # clojure-dev (11)
- # clojure-finland (1)
- # clojure-ireland (6)
- # clojure-japan (3)
- # clojure-portugal (1)
- # clojure-russia (152)
- # clojure-sg (7)
- # clojurebridge (3)
- # clojurescript (86)
- # code-reviews (3)
- # core-matrix (4)
- # cursive (25)
- # data-science (1)
- # datascript (2)
- # datavis (98)
- # datomic (21)
- # dirac (97)
- # emacs (1)
- # hoplon (1)
- # jobs (2)
- # ldnclj (21)
- # off-topic (3)
- # om (204)
- # pedestal (3)
- # proton (12)
- # reagent (125)
- # ring-swagger (9)
- # slackpocalypse (1)
- # spacemacs (1)
- # vim (1)
- # yada (19)
Where is the browser repl (or figwheel interface) in om-next-cross-platform-template? lein repl starts up a clojure repl and clearly figwheel is running in the background somewhere, but how can I interact with the browser repl?
hey everyone. Did someone try to use Firebase (https://github.com/crisptrutski/matchbox) together with Om Native? I’m latest version of matchbox, natal, om-next and having trouble reading data from firebase. Just wondering if anyone tried this setup
We've added source map support to boot-react-native, but there seems to be a noticeable delay when Chrome first loads and parses the source maps - I think due to the size of the source maps (for cljs.core). @drapanjanas or anyone else - have you experienced this problem?
Actually when you run
lein repl the template automatically runs the fighwell repl, so it should be a repl to the browser (or mobile device)
another addition to that -
lein repl starts nrepl session, so just connect your Emacs/Vi/etc. to it
@mjmeintjes: No, first load is fast. I noticed something strange only in stock android emulator (avd). And not the first load but subsequent reloads by figwheel were slow. But that does not happen on genymotion or real android or iOS simulator, I will try to dig in to that some time.
Maybe it worth checking what time does it take for packager to serve the map. I not fully understand the approach but as I understood, map file contents first loaded into a string and only then returned. Maybe that part does not work well with big files. I am olny guessing now :)
In approach implemented in re-natal packager is 'shortcutted' to bypass any processing in case of map file.
I don’t know if this is off-topic, but we’re using cordova to run clojurescript on devices and many of the challenges we’re trying to solve are the same as the react native toolings
If anyone is interested in trying it out I’ve pushed a sample project here https://github.com/frankiesardo/cadabra
that’s out intention. the app is still in development. hopefully should be out in a couple of months
jut curious: why didn’t you choose RN, or Telerick or anything else that provides native UI?
react native looks cool but at the moment cordova is much more mature for our needs :simple_smile:
Mainly because we don’t need native speed. css styling is enough for what we have to deliver
I guess with Cordova you can start much faster and the difference between platforms would be minimal with this approach
we’re currently using om.now for the internal website but we’re planning to use om.next for this app
I need to learn om-next, at least so that I can reason about it with you guys. Usually I like to have application only as complex as it needs to be. So, maybe it would be good to have some lib which you can drop into re-frame application to get 'synchronization part' which @jaen mentioned when you actually need it.
I think the maintainer mentioned that om.next's synchronisation is extractable, but I don't know how true that is. But regardless of that such a library for reagent (or that just works with reagent) would be neat.
It probably should, It's Just Javscript™, but one of the downsides of GraphQL/Relay is that queries are strings, though I imagine building a DSL serialising to such strings shouldn't be that much of a pain.
I'm unsure if it supports the denormalisation and merging om.next does. Though I think I've seen something like that in JS
Probably because they didn't see the need for programmatically composing queries, I suppose.
Well, I didn't have time to try out om.next yet, but I agree with all the ideas it uses re: synchronisation and such. Really well considered stuff.
true. So it’s kinda not fare to compare om-next and reagent - they have different goals
That's true. Even with re-frame is not really fair; it's mostly an event framework, the concern of backend communication is left as an exercise to the user.
Hello, everyone. I've created a weather application using re-natal and open-sourced it. I hope it will be useful for anybody, because I haven't seen any other complex example of native-looking mobile application with reusable components for both iOS and Android. It also uses external APIs and loads data from two different sources. Feel free to add something or send me a couple of comments: https://github.com/alwx/luno-react-native