This is a presentation I made for react aarhus. It focuses on using react, and more importantly react native as a way to write apps that run everywhere.
2. HELLO
WHO AM I?
▸Jan Kjærgaard
▸Writing software since I were 14
▸Started getting paid for software five years ago, full time
professional for two years.
▸React for one and a half years now
12. THE PROBLEM
THE PROBLEM IS COMPLEX
▸Tons of ‘clients’ want access to your service
▸You end up with tons of code and complexity
▸More teams
▸Longer QA time
▸More expensive
▸The should be a better way
13. SOME SOLUTIONS EXISTS
SHARE SOME CODE
▸Share the native code
▸Xamarin
▸Flutter
▸React-native
▸…
▸Web client is still living in its own world.
19. ESSENTIALLY
▸Crossplatform consists of two parts
▸Make sure you code against some API
▸Make sure the API runs on target platform
▸Perform proper bootstrapping of application to run on
platform
21. HTTPS://GITHUB.COM/JANKJR/UNIVERSAL-JS
A LOOK AT A UNIVERSAL JAVASCRIPT
SETUP
▸Code is located at: https://github.com/jankjr/universal-js
express ‘main’
web client ‘router’
native client ‘router’
part of web bootstrapping
22. BOOTSTRAPPING THE WEB APP
HTML.JS
▸Render static website as a
react-like page
▸Pass in bundled
scripts/styles
▸Pre-render current app
state (children)
▸[include tracking/analytic
scripts here as well]
23. PRERENDER APP SERVERSIDE
SERVER.JS
▸Resolve path/query into a
route
▸Render route into a string
and a set of css-rules
▸Emit HTML and javascript
bundles
▸THIS IS serverside
rendering in a nutshell
27. PROS
▸Single language across server, mobile, and web client
▸Code sharing, Less code
▸Smaller team
▸The platform is (Mostly*) abstracted away
* Look, you will fight cross platform incompatibilities, k?
28.
29. DEALING DIFFERENCES
EXAMPLE: LINKS AND BUTTONS
▸Web has the notion of links <a>’s
▸not a thing for apps (Not really)
▸We need some way to toggle between behaviour
31. DEALING DIFFERENCES
STATIC SWITCHING
▸Rewrite imports at build time, as seen by server web pack
config*
* resolve/alias does not work for building node server
▸We’re back to compile-time switches. Like in the good ol’
days.
32. CONS!
NOT EVERYTHING IS GOLDEN
▸There ARE differences in the execution environment
▸Try to solve as many problems using vanilla react-native
components.
▸The web accepts more styling than apps, try to style mobile
first.
▸React native runs future JS. More or less needs a
precompile step
▸Browser != Phone, so you will still do a lot of testing.
Hey everyone!
(I hope you all have had a beer. *drink*. They are over there, and somebody else paid for them. So don’t be shy.)
I hope you are doing well!
Today we are going to be talking about a subject I have been exploring for the past fours months, and have been fascinating me a lot for at least as long as apps and mobile platforms have been around.
That is the notion of true, single codebase, cross platform app.
Inside the JS world, some, me included, have dubbed these technologies universal JS.
But first things first.
My name is Jan.
I have been programming since about 14, my first languages we’re C and Java.
Back end I mostly wanted to make games, then I realised that it was nice to earn a salary as well.
I have been professionally developing software for five years now.
I first heard about this mysterious ‘react’ technology two years ago, but it took me about six month before I really started exploring it.
I expect most of you work in tech some way or another, and therefore probably have developed some wonderful product/service.
I expect your situation to be approximately like this.
And your core technology/service is simply mind blowing
At some point you will have to give your customers access, and instantly it becomes a huge task.
Who knew customers wanted to access your service using more than one platform and expect a good user experience?
Users usually start here, and open up a browser.
So you think, ah, mobile first websites. Easy enough.
Well, at some point they will also access your site using one of these.
At some point they will start complaining, the user experience kinda sucks on the first set of devices.
So you need an app.
Now you have two(or more) code bases serving the same content.
At some point you start getting weird visitors. Clients with very weird user agents.
You have been invaded by indexers. You have to love these guys, they promote your site. But they don’t really care for your carefully crafted JS.
So, your mobile first, desktop friendly mess now has to be served by clients that don’t even want to execute your JS.
But lets hold take a step back for a moment and just focus on the users.
One way to approach this is just to focus on the web. Every user has a device which is capable of executing HTML5 in some way or another.
This is where you scream cross platform. Because YES! The mobile experience does not have to be spread out between multiple codebases.
There is Xamarin, React-native and so on!
But the web client is still living on its own in this setups. Depending on use cases this might not be too bad.
But what I am going to show is that it is possible to use the same code everywhere!
Lets take a look at a typical app.
Usually the code is split into multiple categories handling different responsibilities.
The core is the business logic, handling, app state, authentication, and communication with your services.
Then the view logic handles displaying the the app state. In react this is what you would emit during a render call.
The trick to make something cross platform is making these two layers run on the platform without changing too much of the core business logic.
This is usually it is easy enough to make the core business logic run. Most of what language libraries offer is easy to implement, since all platforms more or work with similar low-level primitives.
The hard part is the view logic.
Lets take a look at a typical app.
Usually the code is split into multiple categories handling different responsibilities.
The core is the business logic, handling, app state, authentication, and communication with your services.
Then the view logic handles displaying the the app state. In react this is what you would emit during a render call.
The trick to make something cross platform is making these two layers run on the platform without changing too much of the core business logic.
This is usually it is easy enough to make the core business logic run. Most of what language libraries offer is easy to implement, since all platforms more or work with similar low-level primitives.
The hard part is the view logic.
Lets take a look at a typical app.
Usually the code is split into multiple categories handling different responsibilities.
The core is the business logic, handling, app state, authentication, and communication with your services.
Then the view logic handles displaying the the app state. In react this is what you would emit during a render call.
The trick to make something cross platform is making these two layers run on the platform without changing too much of the core business logic.
This is usually it is easy enough to make the core business logic run. Most of what language libraries offer is easy to implement, since all platforms more or work with similar low-level primitives.
The hard part is the view logic.
Lets take a look at a typical app.
Usually the code is split into multiple categories handling different responsibilities.
The core is the business logic, handling, app state, authentication, and communication with your services.
Then the view logic handles displaying the the app state. In react this is what you would emit during a render call.
The trick to make something cross platform is making these two layers run on the platform without changing too much of the core business logic.
This is usually it is easy enough to make the core business logic run. Most of what language libraries offer is easy to implement, since all platforms more or work with similar low-level primitives.
The hard part is the view logic.
Lets take a look at a typical app.
Usually the code is split into multiple categories handling different responsibilities.
The core is the business logic, handling, app state, authentication, and communication with your services.
Then the view logic handles displaying the the app state. In react this is what you would emit during a render call.
The trick to make something cross platform is making these two layers run on the platform without changing too much of the core business logic.
This is usually it is easy enough to make the core business logic run. Most of what language libraries offer is easy to implement, since all platforms more or work with similar low-level primitives.
The hard part is the view logic.
I’ve set up a react-native-web project to show one way of configuring such a project, and if you are interested in this topic, I would suggest you should even take a look.
Here is how the code more or less looks like.
One important thing to notice is that we are essentially developing four ‘main’ entries into our program.
There is the static renderer, which is connected to the web and server code. We will explore this in more detail.
Then there is the native and web js. These two define the web app and native app router component respectively.
Both essentially listen for changes in the route, and render the corresponding view based on ‘where’ we are in the application.
Lets take a look at how SSR rendering could look in a react app.
Here is a weird trick, in vanilla react, all html5 tags are valid. Also top level tags such as html.
This means react is actually a very suitable tempting language all on its own. Neat huh?
No more handlebars!
Anyway, the thing that this does is essentially to lay out the base for our web app. This is also where you would configure analytics and the like.
If we take a step up and look at how the serverside router is set up. You will notice that we essentially do one thing.
Resolve the current route. Render current route/state into string. Emit html page for web-client.
