How to Expose macOS Native Modules to React JavaScript

In a previous lesson, we created our own native functionality, but we haven't been able to call it from the JavaScript side yet. So that's what we're gonna explore in this lesson. So I'm gonna go back into VS Code, and we could call our native functions directly, right? We could import a special module from React Native and just start using our functions. However, we're gonna be a little bit smarter about it, and we're actually gonna create a wrapper for our code. So I'm gonna go to my leaves folder within my source folder, and I'm gonna create building apps.native.ts file. I'm just gonna take the code from the course. And let's go over it. So first of all, I'm importing a module from React Native, the native modules. So the native modules exposes a lot of the native functionality in React Native . It will also expose our custom class that we created, which is this one. And right from the start, the ideas that we need to introduce or we want to introduce type safety into our code. So we're gonna create an interface. I'm just gonna call it the interface for building apps native. And I'm gonna type my two methods that I created before. My keychain write, which takes a string and a payload, and returns a promise. And my keychain read, which just takes a key and returns again a promise. Then I'm gonna create, I'm gonna use the same pattern that I used to create my stores, which is a factory function. It's gonna be called create building apps native. And it's gonna take the module, a native module, and it's gonna have an any type anyways, because all the dispos native modules from React Native, they don't have any types by default. And it's gonna return an object with the same interface. So on the body of my function, I can just return an object with the keychain read and keychain write. And I'm just gonna directly bind the expose methods from my native module. Now, how do I get the native module is quite easy. Here you can see I'm gonna export an instance and calling my create building apps native function. And from the native modules object itself from React Native, I'm extracting the same class name that I did on my native code, my objective C code. Now, there's a good thing about this pattern, because it encapsulates certain things that you might not able to do from the native side. So let's say for example, the keychain is only available on macOS and iOS platforms, right? So I shouldn't be able to call this from Android for example, or a Web TV device or something like that. So here I can just use any other module or any other code, even from React Native or from my own application, to disable functionality, right? So I can go something like platform.os is, I just want to make sure that this doesn't crash on the native runtime or something, right? So I can just disable functions as I go or I say please. Great, so the next thing I need to do is I'm gonna one more time add this to my index. I'm really not just native. And finally, I can go into my UI store, because this is the store, if you remember that's holding the actual data, that I'm getting from my server. So this is the store that I want to persist. If you remember the basic idea, why we started exposing the functionality was that we wanted to add persistence to our app. So in order to do this, I'm gonna import first of all my instance of the native code that I created, which is the building apps native from my libster. And in order to do this, we need to talk a little bit about the Mobx store serialization, or how do you serialize Mobx observables? Maybe it would be better if we take a look into the persist function first. So let me just take the code from the course, and I'm gonna create the function out here. So this is my persist function. Now it's an async function, because the keychain right again is async. So if at some point I wanted to change or chain calls, I should be able to await for this function. But actually let me just create it inside of here. Yeah, that works better. Okay, so basically I have a persist function. And inside of this, I'm gonna get a plain state. What does this plain state is supposed to be? It's supposed to be the state of my observable of my entire store, but not as observers or observables or this enhanced object, right? Because you cannot serialize those. If you want to serialize, you want to convert everything into simple objects, right? You want to convert them into JavaScript objects, into arrays, into strings, into numbers. So basically that's what I want, a very simple representation of my store. Now the question is how do I get that? And Mobx provides this helper, which is 2.js, right? It takes Mobx object, it could be an observable, it could be a plain object, it could be anything. And it tries to extract all the red values out of it, you know, and return simple JavaScript. So I'm gonna pass my store into the 2.js function. And once I have my state, I can just write it into my keychain, right? I'm just gonna name it a state, it's quite simple because I'm using the keychain value from my native code, so I don't have to add any special key to it. And then I'm just gonna convert it to JSON, to a plain JSON string, and I'm gonna write that to the database, or to the keychain. Now, the good thing about this, and we will see this in a little bit, is that this 2.js store is recursive. And because it's recursive, it means that if it's registered as an observer, any time, any value of my store, it could be, you know, nested value, right? It could be a property inside of a book, inside of my store. If that changes, this is gonna get picked up, and therefore, the persist function will run again on its own, without me having to do anything to detect the changes. Right, that is one of the great things about observers, again, you don't need to worry how they're being updated, when they're being updated, you just need to access them. And as long as you access them, your code will react to any changes. All right, great, so now we have our persist function. We're gonna move to our hydrate function. So, just put the same code that's on the lesson. Again, hydrate is an async function. And this time is the reverse operation, right? I'm gonna take from my native module, a keychain read, gonna read the same key as before. I have to await it, because it's an async operation, and then I'm gonna get a string state. This is some defensive programming, right? The first time we start the application, nothing will be there. So, if we try to parse it, it's gonna crash, which is not something we want. So, I just check if it exists, then I'm gonna parse it, I'm gonna convert it from JSON into a pure JavaScript object. And then I'm gonna have a plain JavaScript object. We have seen before, anytime that I await any function, and I want to modify my mobic state, I have to run it in an action. So, running action. And then, from my store, I'm gonna take the books, right? So, I'm gonna walk over from my parse store, the books array, gonna map over them. And then I'm just gonna return plain object. And I'm gonna put that array that I iterated upon into my store books. This is a little bit cumbersome, but that's what you need to do, because some of the data, it's in a different format, right? You could put everything, everything, everything in your store, just plain, plain strings, numbers, and everything. And then just generate, use it, compute the property, something like data objects, for example, right? That's also doable, right? This is something that you will need to decide on your application, if it makes sense or not. Great. So, now we have our persist and our hydrate function. We should be able now to connect it to our API store. So, basically, whenever I create my UI store, this is gonna run, I'm gonna create the instance, and after I create the instance, what I want to do is I want to call the hyd rate function. Once hydrate has done its job, because it's an async function, right? I am going to chain another promise, or I'm gonna do something about the state or the new state of the application, and then I'm gonna use another utility, which is auto-run, again, from Mobx, and I'm gonna say persist. So, auto-run is what takes a function that uses observables and turns it into an observer. Basically, if we go back into our Book's container, this observer function is very, very, very similar to this auto-run, if you think about it, right? This observer function turns a regular React component to an observer, right? It tells it whenever any of the observables inside of your body changes, you're gonna re-render. The auto-run function does the same for any generic function, right? It says this function whenever any of the observables you're using changes, you 're gonna re-run yourself. And that's basically it, right? We tell our server to hydrate. After it's hydrated, we can start persisting our state on its own. So, I'm gonna save this. Here is our application. I am going to reload this, and let me think. I should kill my server. And now if I reload it, I have a persisted state, right? Right now it's on handling, and there's an on-handed promise rejection, because it's trying to reach the server, but it doesn't matter.