Mike Haney mdhaney

React Navigation is a great component for building mobile applications. It is versatile and supports both dominant platforms beautifully. However, despite the 2 libraries that exist out there to support this component in the Clojure ecosystem, there is sadly very little documentation on what and how you can set up and use this component. I could not get them to work for me (my failing) so I decided to try and make it work without the existing libraries just to that I can understand what is going on. Below is a laying out of my experience. Let me know if you have corrections so that we mortals who are not that sharp can learn.

React Navigation requires an exact set of steps to make it successfully work

Step 1: Installation of React Navigation

Use yarn to add the library to the project

Externs Inference

Integrating third party JavaScript libraries not written with Google Closure Compiler in mind continues to both be a source of error for users when going to production, and significant vigilance and effort for the the broader community (CLJSJS libraries must provide up-to-date and accurate externs).

In truth writing externs is far simpler than most users imagine. You only need externs for the parts of the library you actually intend to use from ClojureScript. However this isn't so easy to determine from Closure's own documentation. Still in the process of writing your code it's easy to miss a case. In production you will see the much dreaded error that some mangled name does not exist. Fortunately it's possible to enable some compiler flags :pretty-print true :pseudo-names true to generate an advanced build with human readable names. However debugging missing externs means compiling your production build for each missed case. So much time wasted for such simple mistakes damages our sen

finalpage dev gist blog

Writing Generic Components

The React community has gone through several patterns for how to compose React components, but it generally has settled on a few techniques. Which one you use depends on the type of component you are building.

Using `props.children`

The simplest way to make a component more generic is to allow

Recent improvements to the ClojureScript compiler have greatly simplified setting up development versus production outputs.

This example uses Figwheel as something that you want to exclude for production, but the pattern is general.

With this simple setup you only need one html file/view and it will work for developement and production.

	(defn cache-resolver [resolver]
	(update resolver ::pc/resolve
	(fn [resolve]
	(fn [{::keys [persistent-cache*] :as env} input]
	(let [cache-key [(::pc/sym resolver) input (p/params env)]]
	(if-let [[_ v] (find @persistent-cache* cache-key)]
	v
	(let [response (resolve env input)]
	(swap! persistent-cache* assoc cache-key response)
	response)))))))

	(ns ucv.models.user
	(:require #?@(:clj [[datomic.api :as d]
	[ucv.util :as util :refer [spy when-clj]]]
	:cljs [[ucv.auth :as auth]
	[ucv.util :as util :refer-macros [spy when-clj]]])
	[clojure.spec.alpha :as s]
	[taoensso.timbre :as log]
	[fulcro.client.primitives :as prim :refer [defsc]]

	[ucv.util :as util]

	(require
	'[cemerick.url :as url]
	'[clojure.spec.alpha :as s]
	'[clojure.spec.gen.alpha :as sgen])

	(defn non-empty-string-alphanumeric
	[]
	(sgen/such-that #(not= "" %)
	(sgen/string-alphanumeric)))

	**Concerns
	- Interactivity
	-- Incremental extension or modification of running system
	- Modularity
	-- Pluggable serialization, storage, conveyance, scheduling, lifecycle hooks etc etc

	**Spark Summary
	- RDDs: represent a lazily-computed distributed dataset
	-- each dataset is broken up into 'partitions' that individually sit at different machines
	-- just a DAG with edges annotated to describe relationship between partitions of parent and partitions of child

	;; =============================================================================
	;; Composite

	(def composite-data
	{:composite/item {:id 0
	:width 400
	:height 400
	:color "#428BCA"
	:children [{:id 1
	:width 200