Fork me on GitHub
#cljsrn
<
2017-09-04
>
danielneal14:09:43

has anyone hit https://github.com/bhauman/lein-figwheel/issues/596 trying to upgrade to figwheel 5.13 so I can use re-frisk 0.5.0

sllyq18:09:20

I'm seeing :> in a bunch of example what is it?

sllyq18:09:51

Like [:> Text {} "Nothing to see here!"]

carocad21:09:17

@sllyq I think that is reagent way of dealing with components declared as JS classes. Otherwise you are forced to do something like (r/adapt-react-class (.-Text ReactNative))

sllyq21:09:17

Is there some way to get better view of errors

sllyq21:09:35

Because sometimes thing in my app stop working and oftentimes without good indication of what's wrong

sllyq21:09:40

(I'm using basic re-natal setup)

pesterhazy21:09:43

@sllyq yeah getting better errors is a struggle

pesterhazy21:09:51

try the following

pesterhazy21:09:32

1. check the debug log religiously ("react-native log-ios"). It should have at least the exception name

pesterhazy21:09:56

2. you could try the Chrome debugger mode (I don't use it personally)

pesterhazy21:09:32

3. check Figwheel's log (`tail -f figwheel_server.log`) for compiler errors. These don't get as much visibility as on the web. If a namespace doesn't compile and you reload without fixing, things can break pretty thoroughly. Best to go back to a version that compiles and retrace your steps. Always react to compiler errors immediately

pesterhazy21:09:28

4. restart figwheel to surface compiler errors. Sometimes a ns didn't compile without errors, but subsequent compiles won't show the error again. You'll need to restart figwheel and check for any errors and warnings

pesterhazy21:09:40

5. no tolerance for warnings! Fix them

pesterhazy21:09:24

6. errors in render fns are particularly annoying because they break hot reloading. You'll need to reload using Command-R

pesterhazy21:09:30

7. try some tricks I've used to get better error messages in render fns and better stacktraces (the default Red Screens are unfortunately not too helpful without source maps): https://gist.github.com/pesterhazy/e6846be1b6712a9038537022d131ce46

pesterhazy21:09:00

8. finally the standard rules of working with cutting edge tech apply: checkpoint in version control at every known-good point, force yourself to make baby steps so you know what caused breakage, and question your assumptions about how things work, especially when things break