This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-07
Channels
- # beginners (71)
- # boot (25)
- # cider (204)
- # clara (18)
- # cljs-dev (10)
- # cljsrn (64)
- # clojure (50)
- # clojure-dev (2)
- # clojure-dusseldorf (1)
- # clojure-india (5)
- # clojure-italy (1)
- # clojure-nl (21)
- # clojure-poland (65)
- # clojure-spec (41)
- # clojure-uk (10)
- # clojurescript (4)
- # core-async (5)
- # cursive (2)
- # datomic (17)
- # duct (8)
- # emacs (8)
- # fulcro (1)
- # graphql (21)
- # hoplon (2)
- # javascript (3)
- # lumo (25)
- # mount (5)
- # off-topic (5)
- # onyx (3)
- # portkey (6)
- # re-frame (15)
- # reagent (5)
- # rum (1)
- # shadow-cljs (198)
- # spacemacs (19)
- # specter (2)
@mfikes do you think the re-natal template should use :target :nodejs as per your blog post? http://blog.fikesfarm.com/posts/2017-07-17-cleaner-clojurescript-react-native-interop.html
(e.g. is it stable/safe?)
Anyone using Google's Fastlane with cljsrn? https://docs.fastlane.tools/#why-fastlane
@olivergeorge The stuff in that blog post is stable / safe, as far as I can tell. (It is not based on some quirk of the compiler that may go away in the future.) I suspect if the metro bundler vs. :npm-deps
nut is ever cracked then we may end up consuming third-party components this way as well. But in the meanwhile, I see no issue with code being constructed this way, even in templates. I have changed my opinion on constructs like rn/Animated.View
mentioned at the bottom of that post, but that's really a separate subject.
Turns out re-natal require-all
won't discover the require statements in this format.
Thanks for clarifying
As an aside, without the patch in https://dev.clojure.org/jira/browse/CLJS-2739, I've been strongly motivated to avoid having the compiler know about stuff in node_modules
, setting :npm-deps
false
.
I'll keep that in mind. Haven't come across the "metro bundler vs. :npm-deps
nut".
Perhaps that's why the re-natal project.clj file doesn't use :npm-deps at the moment
@olivergeorge When React Native first appeared, David Nolen's inclination was to avoid the bundler, and he drafted a Remote Compilation architecture back in Feburary 2015 https://github.com/mfikes/ambly/wiki/Remote-Compilation We roughly had things working with Ambly this way and managed to get ClojureScript running with React Native
But, this was constantly going against the grain, by essentially ignoring the metro bundler (it was called the React Native packager back then). It took the bulk output of the bundler, and then concatenated ClojureScript's output onto that, and then mutated that via the REPL.
This this an early demo of things working that way https://www.youtube.com/watch?v=Dt2zNemLCCk
That stuff was manually cobbled together, and Dan Motzenbecker put together a system to automate it: natal
: https://github.com/dmotz/natal
Then Will Decker figured out a way that worked with the packager and with Figwheel https://github.com/decker405/figwheel-react-native
And then Artur Girenko ran with that approach, taking natal
and Will's approach to create re-natal
that we know today.
I had wondered about that.
TL;DR, it exists to help React Native work for conventional JavaScript dev, but it doesn't mesh well with the way ClojureScript wants to work with its compilation model.
Maybe Thomas Heller can figure out a way to make things jive with Shadow Cljs, perhaps coming up with a more natural approach.
Thanks for the brain dump.
So looking ahead to an "ideal" approach without the bundler we need to do it all in a clojure build step
Package fetching (:npm-deps)
Compiling with pre-processors (not impossible)
Yeah, if we had enough time, and were sufficiently clever, we could achieve a clean solution that feels more like React for the web
It is truly a fascinating challenge, with some deep technical issues to be resolved, and it is not even clear if they can all be resolved
Given the sheer difficulty with all of this, my stance has been to essentially drop everything and try to put any energy into getting re-natal
to work, even if it is at a "local optimum" and not the long-term best approach. It's the best thing we currently have going.
That'd make a good "trade-off's" section for re-natal. Perhaps including "what would need to change" to move away from local-optimum
Seems a lot better than I remember a year or so ago. Less rough edges.
Oh yeah, I had even gone down the road of https://github.com/mfikes/goby when there was no RN in sight yet. 🙂
This is still one of my favorite tweets on that subject https://twitter.com/andy_matuschak/status/560511204867575808?lang=en
PSA: I had upgraded to Node 10 and started getting bundler errors around fs-events
. Going back to 9.11.1 resolved this.
I've been pondering using re-frame effects to manage React Native animations. Anyone had any good / bad experiences with this?
I'm interested in this. At the moment i keep react native animations in the view layer but it can get a bit verbose. And tricky when the animations get more complex and interdependent
What did you have in mind
Not much more than somehow setting up some effects to act upon animated values. I'm still exploring how to do this, with a hope that the end result works well with re-frame
I did toy with storing animated values in the reframe db and used effects to drive them
But I worried about the inner platform effect - that I might end up trying to recreate the whole animated api as data
At the moment I kind of compromise and keep the values in an Atom outside of reframe but that I can access from an effect if needs be
But not got anything Im super happy with
Here is a version of the core of @olivergeorge’s AsyncStorage
stuff that is written without that intermediate lib (which evidently converts things to promises): https://gist.github.com/mfikes/4ac767c0de05cc127a42c14707723ec4
Nice @mfikes. I wonder when something like react-native-storage would shine. Anyway, for now I've taken your gist as a better approach.
I here by formally acknowledge one of my weaknesses is talking things up and not following through. With that caveat I have a suggestion... how about a series of gists covering each of these specific concerns. @mfikes you talked about a library of these code chunks. It could complement that or really just allow a copy & paste version to the same end.
For example: https://gist.github.com/olivergeorge/6f740bd63d996c31d87de952d51882d1 https://gist.github.com/olivergeorge/9a9d2e1b18e27a0c8c950d64101dd8c4
I'm trying to do this for my dev team who will be working on their first react native app. They do clojurescript daily but there's still lots to get across before you can stop believing in magic.
Here's the list of blog posts I've got at the moment for them... Compiling with :target :nodejs Helpful interceptors Tradeoffs: Embrace or reject the bundler Gotcha #3: I see dead people Gotcha #2: Forgetting to restart the Metro Bundler Navigating between scenes Storing data in the app Store listing details (Google Play Console) Tour of the Azure AD configuration and management Gotcha #1: Forgetting to regenerate index.*.js Authenticating against Azure AD One-off setup of React Native Bindings for the Microsoft ADAL library Figwheel used for REPL and live coding Setup needed to Generate Signed APKs iOS Podfiles
Maybe I'll do that... do you mind if I use some content from your gists @olivergeorge?
Gladly
I'd be happy to point at it from those posts.
I'll put something together... I think these would be generally useful for devs writing RN apps with re-frame
Agreed
I'll post some more of my notes on gist and perhaps that'll inspire a few more additions.
This is the most intrusive / least fx related post I have... navigation
I don't have much experience so would love feedback.