Enjoy the ride! 🚀

Anatomy of Query Components

One of the very powerful concepts that we found for ourselves with Apollo is Query Components. These components are meant to express a domain-specific data logic in a clear, declarative way:

CitiesQuery component is an oversimplified example of an average Query Component. It exports a Component, enhanced by a graphql wrapper for fetching data. After Apollo takes care of fetching and mapping props to query parameters, query component uses “function-as-a-child” approach to expose a child-independent API with injected data.

Comparing to the standard approach where you add a graphql wrapper to your higher-order components, query components have a set of advantages:

• Testability. Unless you have a very good reason, you can test your components without any data management logic.
• Separation of concerns. From now on, higher-order components are no longer concerned about the way data is fetched/pushed to the server.
• Abstraction over data management layer. Frankly speaking, it doesn’t really matter which library you use under the hood. Query Components abstracts out your data management layer so you can focus on business logic and change underlying implementation if needed.

Once a Query Component is defined, it can be used as any other component in your application:

A nice side effect of decoupling higher-order components into Query Components is minimizing bloat. If the data management layer grows, it won’t affect presenter components unless they have to reflect new data properties.

Mutations with Query Components

Mutations are not that straightforward as queries. When a query component is mounted, Apollo immediately tries to fetch. However, when we talk about mutations, there is no need (in 99% of our cases) to perform any mutations at the mount time. This idea brings us to the point that we should have a way to control a moment when we execute our mutations. For example:

Therefore, you can use this component in a similar way:

So the concept is the same: Query Component receives a bunch of props that are later on used as parameters for the mutation query.

How to test Query Components?

When it comes to testing, Apollo-based components have a bunch of features that we need to take into account. The most complicated one is related to React context and Apollo Client reference in particular. All components that intent to use Apollo should be put into the subtree of <ApolloProvider /> which gives them a reference to the client through the React context. Hopefully, if we use Enzyme and shallow rendering, we can supply context object as one of the options.

Assertions

One of the very first things we would like to test is that every Query Component is able to produce variables, required by a query. To ensure that, we check a shape of resulting variables.

Another assertion that we would like to make is about response shape. In other words, we check if given data.x complies with the shape of the mock that was passed to the fake client during initialization.

And the last, but not least: query component should call a function that we pass as a child with the data pulled from Apollo. Altogether, the test suit looks like this:

The very last uncovered function is makeFakeClient. It is a self-written helper that generates an Apollo Client with a fake link:

This should be more or less it. I didn’t cover mutation components testing, but it isn’t anyhow different. The only thing I can foresee is an additional assertion that execute handler triggers Apollo fetcher, but I’ll leave it to the reader.

Where to go from here

• A great blog post from Khan Academy about their approach writing Query and Mutation components

Don’t hesitate to ask questions, challenge this approach and share your ideas about Apollo and GraphQL overall. You can always find me on Twitter or Discord (kureev on #reactiflux).

Oh yeah, and last but not least: if you like this or any other of my articles, don’t hesitate to become a part of it! Your support is greatly appreciated!

Query Components with Apollo was originally published in Apollo GraphQL on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unfortunately, not everyone was able to attend the conference and/or listen to my talk, so for those who are interested, I’d like to provide an article explaining the concept I shared.

Motivation

Nowadays, it is hard to imagine a mobile application without any kind of network communications. Currently, my phone contains more than 40 applications, but there is only one that doesn’t use any of them — calculator. For me it is a solid indicator that it is almost inevitable to avoid writing network-specific code in an average React Native app.

In this article we’ll cover all networking primitives that React Native expose to JavaScript, make a round trip request and discuss most common network issues you may encounter using the platform.

Meet our heroes!

React Native ships with three network APIs available by default: fetch, XMLHttpRequest and WebSocket. There is one thing about all of them that some developers may not know: neither of these APIs is a part of ECMAScript standard which means that JavaScript doesn’t have any standardised ways of transmitting packages over the wire.

Therefore, if we want to perform network requests from JavaScript, we need to extend its runtime by a custom functionality implemented by the underlying host platform (which is React Native in our case).

There is a chance that you are not familiar with terms “runtime” and “host platform”: a runtime represents a complete JavaScript execution environment which means it contains all the APIs that are available for developer. Host platform is a platform that embeds JavaScript language and therefore can extend its runtime (by adding custom variables and functions to it).

If we oversimplify JavaScript runtime, it may look like this:

So it turns out that React Native should supply fetch, XMLHttpRequest and WebSocket APIs to JS runtime. Although, there are no such libraries that would work in appliance with WHATWG specifications (e.g. mimic web behaviour) for React Native target platforms (iOS and Android). That implies React Native should’ve re-implement existing standards and it did.

XMLHttpRequest

XMLHttpRequest (XHR) is an object that is used to interact with remote resources. It was originally designed by Microsoft long long time ago and later on adapted by other browser vendors. Despite the naming, nowadays this object is capable of transmitting different data types (not only XML) and work over various protocols based on TCP.

In React Native, XMLHttpRequest consists of two parts: front-end and back-end. The front-end part is something that you can interact with in JavaScript. It is capable of sending appropriate request data to the XHR back-end which is responsible for processing network request and using underlying mobile platform.

The back-end part of XMLHttpRequest is called Networking. It is an abstraction on top of iOS and Android operating systems that provides a unified API layer that front-end can work with. Implementation of this layer is different for each platform. While on iOS Networking module takes advantage of built-in URLSession, Android version works on top of third-party OkHTTP library that supplies a certain abstraction for low-level Java networking API.

Therefore, once developer make a request, it goes through React Native’s Networking module and underlying operating system right to the requested resource.

Fetch

Fetch is a modern concept equivalent to XMLHttpRequest. It offers a lot of the same functionality as the XMLHttpRequest, but is designed to be more extensible and efficient. It operates Request and Response objects that can be re-used in the following requests.

In modern browsers, this API is a part of WindowOrWorkerGlobalScope mixin that extends global JavaScript scope, however in older browsers and React Native (in order to not to re-implement a new API for both platforms) it uses GitHub’s whatwg-fetch polyfill that relies on XMLHttpRequest implementation, so it implicitly uses React Native’s Networking module under the hood. That implies some nuances that we need to be aware of. For instance, one of the known Networking issues is impossibility of transferring any binary data over the wire that currently leads to workarounds (like working with base64 representation of binary data) and/or third-party solutions (like react-native-fetch-blob). You can learn more about these and other implications in the second part of my ReactNativeEU talk.

WebSocket

WebSocket is a communications protocol, providing full-duplex communication channels over a single TCP connection.

You might already use WebSockets for developing your React Native applications. Every time you start an app in development mode, it creates a WebSocket connection between packager and the app itself, so every time you edit your JS files (or other static assets), it sends a patch signal to the app so it can react to the changes.

As far as WebSocket is somewhat different from a standalone request, there is a separated module called WebSockets that performs as a back-end for the technology. Not hard to guess, that by analogy with XMLHttpRequest, WebSocket also has two different implementations across operating systems. Android is being consistent using OkHTTP library while iOS uses a self-written implementation on top of NSStream.

Networking issues

The second part of this article is dedicated to cover the most common networking issues in React Native. Debugging network requests, sending binary data over the wire and credentials management — today we’ll unveil them all.

Debugging network requests

If you ever developed a mobile application using React Native, you might notice that it exposes a great way of debugging JavaScript code — Chrome Developer Tools (CDT). By a couple of taps your JavaScript can be run in a Chrome service worker that provides a wide set of debugging tools. There is a way to log runtime data to console, profile memory, use breakpoints — almost everything you might need. The only one thing went missing — debugging network requests.

Due to implementation specifics, CDT is not capable of handling network requests. If we consider web platform, XHR, fetch and WebSocket APIs are backed by the browser itself which gives it an advantage of having spies that makes it possible to trace network requests. However, React Native doesn’t use Chrome to make networking requests (all network requests goes through the Networking module no matter what), so it can’t trace them.

There is a way to avoid using React Native networking polyfill (so all requests in CDT will go through the Chrome platform and therefore will become traceable), but that would bring inconsistencies between your runtime environment in CDT and your app. For instance, fetch will become capable of sending binary data in CDT, but throw an error in RN app. This is a thin ice and therefore not recommended to use. Hopefully, there are many alternative ways you can use to debug network requests.

Using TCP traffic monitoring tools

This approach works if you develop using an emulator. All your requests will go through your PC/Mac which means they will be regular HTTP requests* and therefore, become traceable.

By “regular HTTP requests” I mean HTTP requests that are similar to the requests we make in our browsers. HTTP protocol is based on TCP, so most of the traffic monitoring tools will be capable to trace them down.

There is a way of using CharlesProxy, Wireshark or their analogs to get a list of outcoming TCP connections. One (or more) of these connections will be related to the app you’re trying to debug.

Monitoring TCP traffic becomes a little bit more complex when we start developing using real device. In order to monitor traffic from mobile, you need to configure a proxy (it is possible with tools like CharlesProxy (docs), mitmproxy (docs) and some others) and manually re-route application requests through it.

Using XHRInterceptor / WebSocketInterceptor

There is another way of tracing your remote requests: by using interceptors. React Native ships with two interceptors for XMLHttpRequest and WebSockets accordingly. Each one is meant to be used for tracing an appropriate API: XHRInterceptor for XMLHttpRequest and fetch requests, WebSocketInterceptor for WebSocket connections.

These APIs are not documented or exposed as a part of the object, exported by react-native package. If you would like to use either of them, there is no other way than relying on current relative import path (which may change in upcoming versions of React Native).

Hopefully, you don’t have to do any of these by your own. There is a pretty great tool brought to us by Infinite Red called Reactotron. It is a swiss knife for React(+Native) development that provides lots of helpful functionality like debugging network requests, redux actions, sagas and much much more. You can easily find a full list of features on its website.

At this moment, the only solution React Native provides by default is “Networking monitor” that you can enable by shaking your device in development mode. However, the functionality of this tool is very limited to a basic tracing of the request. Hopefully, there are lots of approaches in the community that may slightly improve your experience in this area.

Sending binary data over the wire

Another big topic related to networking issues is about transmitting binary data in React Native. It is not a secret that React Native never supported transferring files out of box. We use various workarounds like converting binary data to base64 strings or third-party solutions like react-native-fetch-blob, but the underlying issue stays unsolved. This part will unveil some internals of the File/Blob management, consider workarounds and potential solutions we can apply to React Native to bridge the gap.

Default JavaScript runtime doesn’t contain File/Blob constructors which makes it impossible to represent binary data. However, all modern browsers enhance a default runtime environment by adding their custom implementations so you can work with file inputs and binary data straight from JS. With these implementations actual binary data is stored on the browser/OS side and the only part which is exposed to developer is a reference wrapped into File/Blob object. Unfortunately, JS environment (and Networking module that exposes provides backend for XHR and fetch) of React Native doesn’t support either of these objects, so there is no “default” way of getting a reference to the file from your code.

Convert binary to base64

Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation.

As far as React Native is not capable of transferring non-primitive data over the bridge (so only serialisable data structures), the only way of getting there is to convert binary format to a string. Base64 sounds like a good solution until we consider a round-trip request:

Imagine we request an image from our server. Not just a URI, but the file itself. Request goes from JS thread through React Native platform to underlying OS and, finally, to the requested resource. That resource (your API, for instance) should respond with a base64 string that will be returned to JavaScript by replaying the request flow in reverse order.

Once response hits the bridge, JavaScript thread should allocate memory, sufficient for representing it. That implies certain performance issues that we want to avoid writing our React Native applications. Most of these problems are outlined in the great article of Tal Kol “Performance limitations of React Native and how to overcome them”.

Furthermore, we also need to render an image. Therefore we supply base64 string as a URI parameter for React Native’s <Image /> tag. At the moment of runtime, JSX tree that React Native compose will be sent to the native thread where the native UI lives, therefore the base64 string we supply will be traveling over the bridge again causing memory spikes and additional performance issues.

Now, when we considered potential issues of using base64, I’d like to focus your attention on the alternative approaches we can use for transmitting binary data in React Native.

Can we do better?

Of course, the problem outlined above is not new and probably every developer who ever had to transmit binary data faced it. This problem inspired many developers to give birth to numerous third-party solutions we can use. Although, the underlying issue is still not solved.

The only solid solution for this problem would be to bridge the missing bits of the standard. Hopefully, some time ago Satyajit Sahoo and Mike Grabowski from Callstack.io created a PR to that add these bits to the WebSocket module. After six months of discussions, rebases and reviews, it has been merged and from now on, the latest versions of React Native supports transmitting binary data over WebSocket protocol (🎉!). Although, it solves only a part of the problem: you still can’t send binaries using Networking module. This part of the issue is still under consideration, but you can keep an eye on the progress of the second PR here. Once it is merged, the problem of transferring binary data in React Native will be closed for good.

Conclusion

React Native is a complex platform in terms of composition of different patterns, libraries and architectural solutions. Network layer is only a one of many interesting topics that powers the platform, although for some reason not covered by the community at all. Hope this article shed some light on the network layer and pushed your knowledge of the platform a little bit further.

Have any questions left? You are very welcome to ask them on Twitter or by commenting on the article below.

All these amazing illustrations were drawn by Nicolas: shadow.x.q84@gmail.com.

Network layer in React Native was originally published in DailyJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Previous article: “How to create your own native bridge. Chapter 1: Designing an architecture”.

What do you know about JavaScript engines? Did you ever try to embed one? In this chapter I’m going to guide you through the dark spooky forest of hosted objects, virtual machines, interpreters and other evil spirits that we call JavaScript engines.

I know that it may look scary, but don’t forget that a journey of a thousand miles starts with a single step. In our case it’ll be a step into code parsing. At this stage our JavaScript source is getting converted to a structure called abstract syntax tree (AST). There are many different techniques to parse your code (LL(k), LR(k) etc) and convert it to AST, but for the sake of simplicity I want to keep it out of this article.

Although, for those who are interested, I got all my knowledge about parsers (and compiler theory in general) from the Dragon Book. I just can’t recommend it enough.

However, I will tell you more about the abstract syntax tree concept. An AST is a structural representation of your code in a tree format where every node represents a language construct (e.g. expressions, statements, variables, literals etc). You can play with it using ESPrima praser demo page or ASTExplorer.

First of all, a JavaScript engine has to parse (tokenize) a source code to produce an array of tokens. These tokens are supplied to a syntactic analysis tool that builds an AST based on a given language grammar. Once an AST is built, JavaScript engine will compile it either to machine code directly (V8 behaves this way) or to intermediate representation, which is an another level of abstraction over machine code.

In this experiment I committed to use ChakraCore which uses a bytecode as it’s intermediate language. But it can’t be executed straight away: our target machine doesn’t know how to process it.

In order to bridge the gap, ChakraCore includes a bytecode interpreter. On ChakraCore’s bytecode each instruction starts with a 1-byte bytecode that represents which operation should be executed (a.k.a. opcode), and therefore the interpreter may have up to 256 instructions. Some bytecodes may take multiple bytes, and may be arbitrarily complicated

That was a very short overview of the JS execution flow. Probably you noticed that in this article we don’t talk about inner code optimizations (like JIT or AoT). Although it’s a very interesting topic, I decided to omit it in order to make this article easier to grasp.

Embedding ChakraCore

Now, when we have some knowledge about ChakraCore, we can start embedding it into our application. So first of all we need to install ChakraCore dependencies:

• $ xcode-select --install
• $ brew install cmake icu4c

And ChakraCore itself. I will show how to include it as a submodule:

• $ mkdir modules && $_
• $ git submodule add https://github.com/Microsoft/ChakraCore

Then build it from the source:

• $ cd ChakraCore
• $ ./build.sh --static --icu=/usr/local/Cellar/icu4c/<version>/include --test-build -j=2

Once these steps are done, we can include it into our application:

• Open the project we created in the previous chapter
• Select ExampleBridge project in the Project navigator and switch to the target:

Link your compiled ChakraCore files:

• libChakra.Pal.a
• libChakra.Common.Core.a
• libChakra.Jsrt.a

And your icu4u files (from /usr/local/Cellar/icu4c/<version>/include):

• libicudata.a
• libicui18n.a
• libicuuc.a

Your result should look like this:

Note: order of these dependencies is very important!

Getting started with ChakraCore

We come to the very interesting part of our journey. To the place where we need all our knowledge about JavaScript engines and the way they work. Yes, dear reader, you’re right! We’re about to start using ChakraCore!

Bootstrapping ChakraCore

First of all, open your ChakraProxy.m file and find the NSLog statement that we added in the previous chapter. Let’s replace it by something that makes more sense:

I don’t expect you to be familiar with Objective C, so let me guide you through this code:

• Line 6–8: Read a content of main.js file from the bundle. More about bundles here.
• Line 14: ChakraCore is an engine, written in C++, so it doesn’t understand NSString format. However, we used Objective C approach to read a file content and now we have to deal with NSString to const char* conversion. So, that’s how we do it.
• Line 24: That’s my custom C++ function. I use it in order to reduce a cognitive payload of run method and move a function description to the different section of this article.

Hope it doesn’t look very complex to you. Anyway, there are still some unclear places in this code:

Runtime

Runtime (line 17) represents a complete JavaScript execution environment. Each runtime that is created has its own isolated garbage-collected heap and, by default, its own just-in-time (JIT) compiler thread and garbage collector (GC) thread. (see ChakraCore JSRT overview)

Execution Context

Context (line 20–21) is an execution environment that allows separate, unrelated, JavaScript applications to run in a single instance of runtime. You must explicitly specify the context in which you want any JavaScript code to be run. (see V8 Embedder’s Guide)

Extending global scope

Now, when ChakraCore is set up, it’s time to build a bridge. In the previous chapter I briefly mentioned that we’re going to use hosted objects to expose C++ functions to JavaScript. So let’s write a function that will do it for us:

If you rewrite the code above to JavaScript, it’ll look like this:

As you can see from the snippet above, we use a special ChakraCore function JsGetGlobalObject to get context’s “global” object. Once it is there, we extend it by a custom hosted object called “bridge” to expose our C++ “render” function to JS. This approach is similar to the one we used in our web applications back in a day. I’m talking about namespaces, when you move all your application modules under window.app or a similar object in order to scope them by an organic global variable. In this code we do the same, but instead of modules we expose a custom C++ function. You are probably wondering why in the code above I use ChakraUtils. It’s a self-written wrapper over a standard ChakraCore API. I won’t go though the code, but you can find my implementation on the github.

However, the “render” function is still has to be defined. It should fit a JS function interface and perform an async dispatch to the main thread. The simplest implementation will look like this:

Try to not to be overwhelmed by the amount of function parameters, in this article we’re about to use only one — arguments. The code above will read the first two parameters passed to the function from JavaScript and invoke an Objective-C AppDelegate method called renderElementOfType . No callbacks, no return values. Let’s keep it simple for now.

One thing, that may make you feel confused is a dispatch_async call. We use this function in order to schedule a block (statement inside ^{}) to be executed in the main dispatch queue (see GCD documentation for details).

Now, once “render” function is invoked, it sends a block to the main thread. Inside the block we have a renderElementOfType call, which is responsible for a final element creation:

You may notice, that we hardcode window and don’t even use a name property. We’ll get back to this part in the third chapter. Other than that, this code should be pretty straight-forward: we create a CGWindow instance and call openWithSize method with a given params.

But when you call this function, you don’t see a window. Why? Because window is a local variable and it will be deallocated once you leave the function scope. So in order to see a window, we have to store a reference to this window somewhere outside of the function. Let’s create a UIManager class that will manage our UI references:

You’re probably wondering what does a sharedInstance mean? It’s one of the ways to create a singleton in Objective C. It’s not necessary to make UIManager a singleton, but to me it feels like a right way to do it.

This class has the only one public API method: addValue. In the next chapter I’m going to add some more (like deleteValue), but let’s keep it as simple as possible for now.

Let’s update our renderElementOfType function to start using our storage:

So once we get a UIManager instance, we generate a uuid for our window and put it in the storage by addValue. Inside the manager we generate a strong reference to the given object which prevents it from being deallocated (see ARC).

And you know what? That’s it! If you create a main.js file, add it to the bundle and type something like bridge.render('Window', 400, 400);, you’ll see a 400x400 window at the application startup!

Buy hey, it has nothing about React yet! What do we need to provide for a React-like interface to our platform? How to return references from Objective-C to JS? All these questions will be answered in the Chapter 3!

In the meanwhile, you can play around with the code from this article.

I’ve been using React Native for a while before I started to dive into the codebase to see how it works. Since then I’ve made quite a few contributions to the project and even managed to become a part of react-native core team.

Although, one part of the project was truly mystical to me — how it bridges two different languages: JavaScript and Objective C. This lack of understanding gave me the motivation to do some research on the bridge and document my findings in these articles.

No doubt, it is pointless to write code without having a clear mental picture of the finished product (or a milestone). Architectural design is an important step of software development. I will try to guide you through the thought process and explain in detail what decisions were made and why.

First iteration

When you start a new project, it makes sense to determine a list of technologies you’re going to use. In my case they were:

• Objective C to manipulate Cocoa UI
• C++ to work with JSVM
• JSVM (V8 or Chakra)
• JavaScript
• React + custom renderer

I assumed my main executable will be written in C++. It will run a JS engine with a patched global context (all major JS engines provides you a possibility to extend their built-in functionality by custom objects/functions). Don’t be afraid of “patched global context”, it means nothing but adding a few new functions written in C++ to your JS environment. Later on, we will talk about it in details.

Once we call one of these custom JS functions, it goes through the JSVM (JavaScript Virtual Machine) and invokes a C++ implementation, which in turn, triggers the Objective C code to construct a UI element. It may sound a bit complex, but don’t give up yet!

All these things can be run in the same (main) thread, but it’ll cause certain performance issues. To avoid that, we dedicate a new thread to handle Objective C ↔ UI jobs.

Even though this approach makes sense, it doesn’t work.

The problem is that Apple doesn’t allow you to render your UI in non-main thread. Moreover, if UI can be rendered only in the main thread, it means that Objective C should be run in the same thread as well. Unfortunately, this approach ties your application’s entry point to the platform (or, at least, makes it really complicated to run it on the other platforms). But we have what we have. Let’s change our initial approach to fit this requirement.

Corrections

If we have to run a UI in the main thread, let’s do it! Instead of running a C++ program, we run a Cocoa application. When its bootstrapped, we spawn a new background thread with a JSVM on board. JSVM runs the main JavaScript file (your bundle) in order to get instructions to execute. As in the previous approach, if you have any proxied C++ functions in your JS code, JSVM will take care of them. Once one of those functions is called, it sends a command to the main thread to draw UI.

In the main thread, Objective C process is given a command and renders an appropriate interface element for it. If there are no errors, Objective C triggers a callback that has been passed in from C++ in order to call a function representing a callback from JS.

Final architecture

Now, let’s try to combine all these together:

• We start a native Cocoa Application because we need to run UI in the main thread.
• Right at the moment when our blank application is bootstrapped, we create a new thread with JSVM. Once it’s done, we run JavaScript. As I said above, we patch our JSVM context and expose some additional APIs to manipulate the user interface layer.
• Once we receive a command from JS to draw UI, we dispatch it to Objective C. In it’s turn, Objective C parses the command and renders appropriate UI elements.
• After that, Objective C invokes a sequence of callbacks in order to pass a return value to JS.

Building a platform foundation

Time for the hands on experience! First of all, let’s create a blank OS X Cocoa Application:

Once this step is done, you have your foundation. Now, if you open your AppDelegate.m, you will find two application lifetime hooks: applicationDidFinishLaunching and applicationWillTerminate. Our application should spawn a new thread at the moment of creation, so let’s change our applicationDidFinishLaunching to do the trick:

Now I have to answer two questions:

• What is a _jsvmThread variable?
• What does @selector(runJSVMThread) mean?

_jsvmThread is nothing else but an instance variable that stores a reference to our new NSThread. We need this reference in order to execute our C++ callbacks in the proper thread.

Selector, according to Apple’s docs, is the name used to select a method to execute for an object, or the unique identifier that replaces the name when the source code is compiled.

In other words, we initialize a new NSThread and run runJSVMThread method of object self (which points to the current instance of the class) in it.

Here’s the body of runJSVMThread method:

As you can see, I decided to use ChakraCore instead of V8. There are some reasons for that:

• It took me 1 hour to compile V8 and 2 hours to run HelloWorld example
• ChakraCore took me 10 mins to compile and run HelloWorld example

Side note: since we’re building a prototype, I would prefer better developer experience that I have with ChakraCore.

Right after ChakraProxy initialization we have a run loop. We use it here to keep our thread alive (otherwise it’ll die after run function is finished). If you want to know more about run loops, Apple docs is a good place to start.

Now we have an application that starts, spawns a new thread and waits for commands. Next step would be to define a ChakraProxy class.

ChakraProxy is just a container which encapsulates Objective C and C++ code:

Of course, this code doesn’t do anything handy yet, but gives you a room to maneuver. In the next chapter we’ll add some fancy things like ChakraCore, basic bridging model and way, way more.

In the meanwhile, you can play with the code in my github repository.

Want to know more about runtimes, contexts, scopes and their implementation? Or maybe extend idiomatic JavaScript by adding your own C++ functions?

All these and even more awaits you in the Chapter 2: JSVM and the first adventure.