Fork me on GitHub
#cljsrn
<
2018-05-21
>
Oliver George04:05:46

I've finally achieved some level of confidence with my basic react native / re-natal stack.

Oliver George04:05:24

Includes codepush which means deployments for most business logic is a lot simpler. MS deserve a pat on the back for that.

Oliver George04:05:37

Just wanted to share.

Oliver George04:05:47

Roll on business features.

Oliver George05:05:01

Here's how we navigated the maze and got to what seems like a productive setup: https://confluence.condense.com.au/display/IZ/

👍 8
dotemacs08:05:49

Thanks for this

Oliver George07:05:17

Is catching/showing thrown exceptions a known issue? This is what I get when my check-and-validate detects the app-db isn't valid. 1. eats the error 2. red error box shows "Uncaught [object [Object]]"

Oliver George07:05:54

The work around seems to be using js/console.error instead of throw. (If that's the case perhaps it's a better default in the template.)

(defn check-and-throw
  "Throw an exception if db doesn't have a valid spec."
  [spec db [event]]
  (when-not (s/valid? spec db)
    (let [explain-data (s/explain-data spec db)]
      (js/console.error (ex-info (str "Spec check after " event " failed:") explain-data)))))

carocad08:05:30

@olivergeorge from what I know if you throw an error it will be catch and re throw several times before it is printed on the screen. Console error does it immediately which is why you see a different behavior. I think this is related to the code reloading that both react natives and figwheel do in the middle

Oliver George09:05:57

Thanks. I guess that makes sense. If that's the case I might log a re-natal issue suggesting the change.

tianshu08:05:59

@jeluard is it possible for clj-rn to bundle the packager so user don't have to start 2 processes?

jeluard09:05:32

That’s something we might want to do yes. Would you want to create an issue with more details about this?

tianshu08:05:46

shadow-cljs has this kind of support for expo, it's really convenient.

thheller08:05:26

@doglooksgood the expo support is probably going away. too many limitations and trying to keep that in sync with expo itself is too much work.

thheller08:05:08

I mean the "not running expo tools" support. you'll still be able to use it but not without running the default RN tools

tianshu08:05:55

You mean use the npm start with shadow-cljs together?

thheller08:05:45

I mean the build support itself is solid but the problem is that you are missing out on most development features built into expo/metro

tianshu09:05:19

It's likely only missing the chrome console here

thheller09:05:18

yeah but I couldn't get source maps working properly either

tianshu09:05:39

the chrome devtools actually provide three things I think: 1. the console output 2. source map 3. the debugger(probably not work very well with cljs because the dirac not work with RN yet)

tianshu09:05:54

since there's a repl with shadow-cljs, I still can get the console output. the only thing missing is source map.

tianshu09:05:43

I don't think it's a big problem. the advantage for the current stage is obviously, it's really convenient.

thheller09:05:05

yeah I still like the idea and if someone wants to "finish" and maintain it I'm all for it but it is not feasible for me to keep up with expo and metro

thheller09:05:20

it might be a necessary evil to use the standard RN tools until they become more customizable. the "hack" I have done is pretty limited though so I can't really take it any further

tianshu09:05:51

I think you don't have to remove it at these moment, maybe I can help a little.

tianshu09:05:00

I don't think I can improve it now because I'm a kind of n00b. but I'm trying to write an app with expo and shadow-cljs.

thheller09:05:42

well how you write it is not going to change. you just might need to run npm start in addition to shadow-cljs watch

tianshu09:05:34

well, it's not so bad