Clojurians
#cljsrn
<
2016-01-25
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

seantempesta00:01:45

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?

podviaznikov03:01:23

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

mjmeintjes06:01:03

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?

artemyarulin06:01:55

@seantempesta: https://github.com/artemyarulin/om-next-cross-platform-template/blob/master/resources/leiningen/new/om_next_cross_platform/project.clj#L13-L14 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)

artemyarulin07:01:41

another addition to that - lein repl starts nrepl session, so just connect your Emacs/Vi/etc. to it

drapanjanas07:01:07

@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.

drapanjanas07:01:05

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 :)

drapanjanas07:01:47

In approach implemented in re-natal packager is 'shortcutted' to bypass any processing in case of map file.

frankie10:01:00

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

frankie10:01:26

e.g. hot code reload to three platforms simultaneously

frankie10:01:56

If anyone is interested in trying it out I’ve pushed a sample project here https://github.com/frankiesardo/cadabra

artemyarulin10:01:43

@frankie: Cool. Do you use that in production already?

frankie10:01:26

that’s out intention. the app is still in development. hopefully should be out in a couple of months

artemyarulin10:01:10

jut curious: why didn’t you choose RN, or Telerick or anything else that provides native UI?

frankie10:01:12

react native looks cool but at the moment cordova is much more mature for our needs :simple_smile:

frankie10:01:00

Mainly because we don’t need native speed. css styling is enough for what we have to deliver

artemyarulin10:01:14

I guess with Cordova you can start much faster and the difference between platforms would be minimal with this approach

artemyarulin10:01:50

Do you use any client side frameworks? React/Reagent/Om?

frankie10:01:37

we’re currently using om.now for the internal website but we’re planning to use om.next for this app

artemyarulin10:01:01

:thumbsup: Om-Next is awesome for mobile

dvcrn10:01:22

re-frame + reagent all the way :stuck_out_tongue:

jaen10:01:54

You lack the nice synchronisation part then, though.

drapanjanas12:01:46

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.

jaen12:01:29

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.

artemyarulin12:01:17

well, you can always take GraphQL + Relay. That’s what React people do

artemyarulin12:01:04

not sure though about RN support of those

jaen12:01:36

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.

jaen12:01:15

I'm unsure if it supports the denormalisation and merging om.next does. Though I think I've seen something like that in JS

artemyarulin12:01:04

yep, I still wonder why the hell they choose to use strings for queries

jaen12:01:08

Probably because they didn't see the need for programmatically composing queries, I suppose.

jaen12:01:17

But this seems like a fairly obvious thing to be wanting to do.

artemyarulin12:01:50

well, whatever - I’m fine with om-next :simple_smile:

jaen12:01:30

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.

artemyarulin12:01:10

true. So it’s kinda not fare to compare om-next and reagent - they have different goals

jaen12:01:34

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.

alwx23:01:57

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