Fork me on GitHub
#cljsrn
<
2019-06-05
>
Oliver George02:06:23

If anyone is interested, I'd love to collaborate and build this out so that it's a well reasoned approach to clojurescript / react-native app development... https://github.com/condense/mercury-app/wiki

👏 8
👍 8
anish08:06:57

I would like to help, however i am not expert on clojurescript and rn-app

Oliver George20:06:20

Thanks @UCFCGU82G. Fresh perspectives are valuable. :-)

scknkkrer22:06:39

I was thinking the same idea. But, with a little bit difference. My perspective was a lot of big. What do you think about to make it more general, more abstract @olivergeorge?

Oliver George01:06:09

I can imagine it growing but proving the approach on something bounded seems sensible first.

scknkkrer19:06:55

@olivergeorge, I can help you. But, I am on a project now. Let me finish it first. We can contact via Github.

magomimmo09:06:29

@olivergeorge that's interesting. I just started to customize the react-native-website for clojurescript, because next september we'll have 2/3 internships resource willing to learn ClojureScript/RN and they are going to porting most of the RN material on ClojureScript. It will be great to not fragment the efforts of the community. Ma personal opinion is that working with cljs on RN is much more productive than working with JS. I also think that it even better that working with flutter too (to much OO theere). Let me know what you think about this initiative.

👏 12
emil0r09:06:06

@magomimmo I like it very much. I had to dig through an awful lot of snippets and various resources to get something going. Then I hit a wall where I needed to know how RN differs from web development which is what I’m used to. I’m coming from a very different angle though compared to most people 😛

magomimmo09:06:38

@emil0r good to know you like it. Let's wait for @olivergeorge feedback.

Oliver George10:06:43

@magomimmo I remember going through your modern-cljs stuff on github ages ago. Found it very useful at the time. I wonder if that's been in the back of my mind as the sort of thing I wanted to contribute to the cljsrn world...

magomimmo14:06:31

@olivergeorge yep it was ages ago 😞

Oliver George10:06:11

Porting the RN documentation sounds complementary and useful for getting over the niggling differences between JS and CLJS.

Oliver George10:06:30

(tell me if I misunderstood any of that)

dotemacs10:06:48

@olivergeorge this project that you posted about above mercury-app, the wiki attached to it, is that a migration from the Jira/Atlasian wiki that you compiled about a year ago ?

Oliver George10:06:18

@dotemacs yes, revisiting after some experience and written for the latest re-natal release

dotemacs10:06:56

Very nice, thanks 🙂

dotemacs10:06:19

@magomimmo there is a repo by somebody who already went through all the JS examples from the official documentation and created ClojureScript equivalent ones for comparison… I’ll see if I can dig it up, it might help with this effort

dotemacs13:06:47

Hi, just found the link to the repo I mentioned earlier, it’s by @U0EQ27WF3 see: https://github.com/rockiger/re-natal-tutorial Maybe your write up can be combined by the examples @U0EQ27WF3 has in his repo in order to produce more featured information point? Also, the react-native team will now feature in their initial app, the links and examples on how to do pretty much all the sample apps that are featured in the main react native tutorial, here: https://facebook.github.io/react-native/ so it might be an idea to unify the efforts?

vikeri10:06:41

@olivergeorge @magomimmo Great job guys! We’ll also onboard people soon, super useful! Make sure to add it to https://cljsrn.org/

magomimmo16:06:00

@olivergeorge @vikeri my idea is quite simple. You have react-native and flutter. We're on the react-native side of the battle. Both JS and DART to me are very, very, noisy languages. We have CLJ/CLJS, which has the less noisy syntax of the three. Dart/Flutter has a very good documentation and development environment (vsc with flutter is very good). React-Native docs is not at same level. We should be able to create a good documentation for cljs/rn beginner and intermediate level as well.

magomimmo18:06:56

and has to be very good looking too 🙂

Oliver George01:06:48

Big +1 there. Presentation matters.

Oliver George01:06:24

I'd be happy to be part of a well presented website with that focus.

magomimmo07:06:03

great @olivergeorge What is you time zone?

Oliver George09:06:51

+10. I’m in sunny Tasmania.

Oliver George10:06:52

Cool. I put my stuff on github this time in the hope of encouraging some contributions.

Oliver George10:06:49

I really would enjoy fleshing out some of the decisions/tradeoffs required to build up a productive codebase

vikeri10:06:32

Yeah, we have a pretty large code base with 17000 lines of cljs and about 6000 commits. For us the secret sauce has been re-frame plus spec.

👍 8
Oliver George11:06:27

Sounds like you might have some proven approaches we could incorporate.

dotemacs11:06:13

This is really cool to see this enthusiasm!

vikeri11:06:43

Yeah I guess we have a couple of useful things. But re-frame does the bulk of the work. Some things we do that are useful is: - Isolate all communication with the external npm dependency into its own ns - Using reagent track to “observe” subscriptions and react to accordingly. For example we bind the network status to a re-frame handler and when that updates the db then the network observer function is run and can do necessary actions based on network status - We have developed a fairly sophisticated logging macro that logs both to the console but also saves the data to disk so that it can be analyzed in the cloud in production. It even has colors when printing to the dev console in log. - We have all components in separate nses - i18n is just fetching keys from a map, very basic but works very well. - Separate config files depending on env (dev, staging, prod, test)

clj 4
vikeri11:06:06

Yeah exactly, that’s a good pattern

Oliver George11:06:39

Thanks for these points. I hadn't come across track before.

vikeri11:06:47

Yeah track is great. Then the handler can just update the state and side-effects due to updated db can run in the observer. Then you always catch if a specific key has been updated.

Oliver George01:06:37

Seems like a good alternative to interceptors where you might forget a handler which causes change. I'm about to make an app "offline capable" so I'll give this a go.

Oliver George01:06:15

(still want the re-frame guys to come up with some clever state machine solution for these types of problems)

dotemacs11:06:20

What’s the testing story on your end @vikeri?

dotemacs11:06:17

I know you spoke of some unit testing approaches with enzyme and such at ClojuTRE, but that’s from a few years ago…

vikeri11:06:17

We have automatically generated tests for all subscriptions to make sure that what they return is compliant to their spec. Then we write unit tests for complicated parts of the business logic. But we’ve abandoned enzyme since we never have any UI bugs :man-shrugging: (thanks to re-frame). We run all the tests in nodejs with the RN requires mocked out using mockery.

👍 4
Oliver George11:06:14

@vikeri do you have trouble with complex generators running out of memory?

vikeri11:06:30

complex generators?

magomimmo11:06:04

today I'm very busy....I'l try to be more detailed in the next fews days. My idea is that we should target both react and flutter communities, because, well ...because CLJ/CLJS is just better 🙂

Oliver George11:06:40

Sounds good to me. Look forward to hearing your thoughts when you have time.

Oliver George11:06:11

@vikeri yes. In my early pokings with complex generators I found that my generators didn't terminate. As an extreme example generating a random app-db based on specs.

vikeri11:06:25

Ah, I see you mean spec generators? Yeah that happens all the time, for complex data structures we’ve written our own generators.

vikeri11:06:50

And for spec testing the rest of the codebase we only do the test with sample size 1

vikeri11:06:23

But for testing the subscriptions we actually mount a dummy db and run the subscription on it

Oliver George11:06:03

Gotcha. Glad it's not just me 🙂

vikeri11:06:11

Since spec is so flexible and can be very specific it can make it very hard to generate data structures with specific requirements.

Oliver George11:06:18

I've been meaning to try using datascript to build up a generated relational dataset... layer on records and link them up as I go.

Oliver George11:06:48

I'm a fan of spec but it's still early days in some ways.

vikeri11:06:13

Yeah regarding storage I was looking at datascript but we ended up just serializing the whole db with transit and saving it to disk. Simple but works well.

dotemacs11:06:06

What do you use for your CI? Some hosted solution or do you roll your own?

dotemacs11:06:29

Is that a private image ?

dotemacs11:06:39

I’m getting a 404 for that URL.

dotemacs11:06:16

Cool, thanks. That works for Android. Do you not have an iOS app or…?

vikeri11:06:15

We do, but we don’t test the build there atm. And since we run all the tests in node we aren’t running any “real” tests on the devices. We just test that the Android app is successfully built. Would love to fire it up as well to see that it doesn’t crash on startup. But couldn’t get that working back in the days when RN was fresh and haven’t properly researched it since.

👍 4
dotemacs11:06:53

Aha, cool. Thanks.

Oliver George11:06:47

I'm off to watch Good Omens and head to bed. Have great days everyone.

vikeri11:06:08

Thanks! Enjoy!