We find the good parts in the products that we use. We value simplicity, and when simplicity isn't offered to us, we make it ourselves. My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.

My notes of JavaScript: The Good Parts

The value NaN is a number value that is the result of an operation that cannot produce a normal result. NaN is not equal to any value, including itself. You can detect NaN with the isNaN(number) function.

The \u convention allows for specifying character code points numerically.
"A" === "\u0041"

(Talking about the for-in statement)
It is usually necessary to test object.hasOwnProperty(variable), to determine whether the propety name is truly a member of the object or was found instead on the prototype chain.

The values produced by typeof are 'number', 'string', 'boolean', 'undefined', 'function', and 'object'. If the operand is an array or null, then the result is 'object', which is wrong.

JavaScript is a prototypal inheritance language. That means that objects can inherit properties directly from other objects. The language is class-free.

If a function is invoked with the new prefix, then a new object will be created with a hidden link to the value of the function's prototype member, and this will be bound to that new object.

When a function is not the property of an object, then it is invoked as a function:
var sum = add(3,4)
When a function is invoked with this pattern thisis bound to the global object. This was a mistake in the design of the language. Had the language been designed correctly, when the inner function is invoked, this would still be bound to the this variable of the outer function.

Because of a design error arguments is not really an array. It is an array-like object. arguments has a length property, but it lacks all of the array methods.

Some languages offer the tail recursion optimization. This means that if a function returns the result of invoking itself recursively, then the invocation is replaced with a loop, which can significantly speed things up. Unfortunately, JavaScript does not currently provide tail recursion optimization. Functions that recurse very deeply can fail by exhausting the return stack.

Most languages with C syntax have block scope. All variables defined in a block ( a list of statements wrapped with curly braces) are not visible from outside of the block. The variables defined in a block can be released when execution of the block is finished. This is a good thing.
Unfortunately, JavaScript does not have block scope even though its block syntax suggests that it does. This confusion can be a source of errors.
(As of ES6, const and let variables are block-level scoped. var variables still are not.)

It is important to understand that the inner function has access to the actual variables of the outer functions and not copies in order to avoid the following problem:

//BAD EXAMPLE
// When you click on a node, an alert box is supposed to display the ordinal of the node. But it always displays the number of nodes instead.
var add_the_handlers = function(nodes) {
    var i;
    for(i = 0; i < nodes.length; i += 1) {
        nodes[i].onclick = function(e) {
            alert(i);
        };
    }
};

//BETTER EXAMPLE
//Make a function that assigns event handler functions to an array of nodes. When you click on a node, an alert box will display the ordinal of the node.
var add_the_handlers = function(nodes) {
    var helper = function(i) {
        return function(e) {
            alert(i)
        };
    };

    var i;
    for(i = 0; i < nodes.length; i += 1) {
        nodes[i].onclick = helper(i);
    }
};

The general pattern of a module is a function that defines private variables and functions; creates privileged functions which, through closure, will have access to the private variables and functions; and that returns the privileged functions or stores them in an accessible place.

• Every function gets a prototype object because the language does not provide a way of determining which functions are intended to be used as constructors. The constructor property is not useful. It is the prototype object that is important.

Constructing an object with the new keyword from a function is a 3 step process.

Example:

 function Mammal(name){
   this.name = name;
 }

  const mammal = new Mammal();

1. Create a new empty object, setting its proto property to the .prototype property of the function invoked with the new keyword. (Functions have a .prototype property, objects do not)(An empty object is created which looks like {}. The proto property of the empty object is set to an empty object which has a proto and a constructor property, the value of which is the Mammal function )
2. Execute the code inside the constructor, setting the instance variables on the newly created object, if any, in the process.
   (the only code inside the Mammal constructor sets the name instance)
3. Return the newly created object.

• Inheriting in JS is setting the prototype property to an INSTANCE of the base class.

Object specification
It sometimes happens that a constructor is given a very large number of parameters.
This can be troublesome because it can be very difficult to remember the order of the arguments. In such cases, it can be much friendlier if we write the constructor to accept a single object specifier instead. That object contains the specification of the object to be constructed. So instead of:

var myObject = maker(f, l, m, c, s);
//we can write

var myObject = maker({
    first: f,
    last: l,
    middle: m,
    state: s,
    city: c
});

Instead, JavaScript provides an object that has some array-like characteristics. It converts array subscripts into strings that are used to make properties. It is significantly slower than a real array, but it can be more convenient to use. Retrieval and updating of properties work the same as with objects, except that there is a special trick with integer property names. Arrays have their own literal format. Arrays also have a much more useful set of built-in methods.

• The length property is the largest integer property name in the array plus one. This is not necessarily the number of properties in the array:

var myArray = [];
myArray.length   //0

myArray[1000000] = true;
myArray.length   //100001
//myArray contains one property.

(JS arrays are sparse arrays in most implementations)

The [] postfix subscript operator converts its expression to a string using the expression's toString method if it has one. That string will be used as the property name. If the string looks like a positive integer that is greater than or equal to the array's current length and is less than 4,294,967,295, thenthe length of the array is set to the new subscript plus one.

Since JavaScript's arrays are really objects, the for-in statement can be used to iterate over all of the properties of an array. Unfortunately, for-in makes no guarantee about the order of the properties, and most array applications expect the elements to be produced in numerical order. Also, there is still the problem with unexptected properties being dredged up from the prototype chain.
(With ES6 you can use for-of to iterate arrays in numerical order)

Your comparison function should take two parameters and return 0 if the two parameters are equal, a negative number if the first parameter should come first, and a positive number if the second parameter should come first.
(The function basically answers the question: 'Should I swap these two params?')

The search method is like the indexOf method, except that it takes a regular expression object instead of a string. It returns the position of the first character of the first match, if there is one, or -1 if the search fails. The g flag is ignored. There is no position parameter.

Global Variables
The problem with JavaScript isn't just that it allows them, it requires them. JavaScript does not have a linker. All compilation units are loaded into a common global object.

In most languages, it is generally best to declare variables at the site of first use. That turns out the be a bad practice in JavaScript because it does not have block scope. It is better to declare all variables at the top of each function.

Implementations disagree on the type of regular expression objects. Some implementations report that: typeof \a\ is 'object', and others say that it is 'function'. It might have been more useful to report 'rexexp', but the standard does not allow that.

Binary floating-point numbers are inept at handling decimal fractions, so 0.1 + 0.2 is not equal to 0.3. This is the most frequently reported bug in JavaScript, and it is an intentional consequence of having adopted the IEEE Standard for Binary Floating-Point Arithmetic (IEEE 754). This standard is well-suited for many applications, but it violates most of the things you learned about numbers in middle school.
(Note, that this is not specific to JavaScript.)

JavaScript has a surprisingly large set of falsy values:

undefined and NaN are not constants. They are global variables, and you can change their values. that should not be possible, and yet it is. Don't do this.
(Really, don't!)

The eval function also compromises the security of your application because it grants too much authority to the eval'd text. And it compromises the performance of the language as a whole in the same way that the with statement does.

The Function constructor is another form of eval, and should similarly be avoided.

The browser provides setTimeout and setInterval functions that can take string arguments or function arguments. When given string arguments, setTimeout and setInterval act as eval. The string argument form also should be avoided.

In my own practice, I observed that when I used ++ and --, my code tended to be too tight, too cryptic. So, as a matter of discipline, I don't use them anymore.

In many languages, void is a type that has no values. In JavaScript, void is an operator that takes an operand and returns undefined. this is not useful, and it is very confusing. Avoid void.

However, apple strongly recommends using Universal Links instead of URL schemes as they are more secure, albeit not as quick and easy to implement as URL schemes.

Limitations

You can't just register any URL scheme, as some are reserved for system apps. Following is a list of such URL schemes: http, https, tel, sms, facetime, facetime-audio, mailto. You can, however, launch the applications that support these URL schemes from within your app. More on that later.

How to set up a URL Scheme for your app

First, come up with the format for your app's URLs. We'll go with celsiusapp://

Now, you should register your URL scheme. This will allow the system to redirect this URL scheme to your app. Do this by navigating to the Info tab in Xcode and scrolling down to "URL Types". Click the "+" to add a new URL type.

Enter "celsiusapp" in the URL Schemes input field and "com.celsiusnotes" in the identifier field. The identifier serves to distinguish your app from others that have registered support for the same scheme. It is recommended to use a reverse DNS string of a domain that you own. Note, that this does not prevent other apps from registering the same scheme with the same identifier - even if they don't actually own that domain - and handling the URLs associated with that scheme and identifier.

Select "Editor" in the Role dropdown. Editor is for schemes that your app defines, while Viewer is for schemes that your app does not define but can handle.

Go ahead and build and run your app. Open Safari in your simulator or on your device and type in "celsiusapp://" in the address bar and hit enter. You should be prompted by Safari, asking whether you would like to open that page in the app you just built.

Handling URLs

As you might know, a URL consists of more parts than just the scheme. There is also the hostname, the path and the query (port number and fragment are not relevant here). When your app is opened through a URL scheme you have registered for it, it can handle the URL string upon being opened.

If your has not opted into Scenes, you will have to implement the application(:open:options:) method in the AppDelegate.swift file to handle incoming URLs. If, on the other hand, your app has opted into using Scenes, as is the default for Xcode 11 and iOS 13, then you will have to implement the scene(_:willConnectTo:options:) and the scene(_:openURLContexts:) delegate methods in the SceneDelegate.swift class. The former delegate method is called when your app is launched, regardless of whether it was launched via a URL, while the latter will be called when your app is opened via a URL while running or after having been suspended in memory.

While opted into Scenes

We're going to write a function to handle incoming URLs for both the scene(_:willConnectTo:options:) and the scene(_:openURLContexts:) delegate methods.

The handleUrl() function below accepts a URL as its only parameter and dissects that URL into its constituent parts: host, path and params. The function will prematurely return, should any of those parts not exist.
Then the function simply prints out the host, all path components and the keys (names) and values for all query parameters. In a real app, instead of simply printing out those parts, you would of course take some action, like navigating to a certain screen in your app based on the path and showing certain items based on the query parameters.

    func handleURL(url: URL) {

        // A host, a path and query params are expected, else the URL will not be handled.
        guard let components = NSURLComponents(url: url, resolvingAgainstBaseURL: true),
            let host = components.host,
            let _ = components.path,
            let params = components.queryItems else {
                NSLog("Invalid URL. Host, path and query params are expected")
                return
        }
        
        NSLog("host: \(host)")
        
        for (index, pathComponent) in url.pathComponents.enumerated() {
            NSLog("pathComponent \(index): \(pathComponent)")
        }
        
        for query in params {
            if let value = query.value {
                NSLog("Query param \(query.name): \(value)")
                continue
            }
            
            NSLog("Query param \(query.name) has no value")
        }
    }

To handle incoming URLs we simply call this function in both the scene(_:willConnectTo:options:) and the scene(_:openURLContexts:) delegate methods:

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let _ = (scene as? UIWindowScene) else { return }
        
        
        // Since this function isn't exclusively called to handle URLs we're not going to prematurely return if no URL is present.
        if let url = connectionOptions.urlContexts.first?.url {
            handleURL(url: url)
        }
    }

    // This delegate method is called when the app is asked to open one ore more URLs.
    // We're only going to handle one URL in this post. Handling, multiple URLs, however, is simply a matter of applying
    // the code to all other URLs in the `URLContexts` set.
    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        // Get the first URL out of the URLContexts set. If it does not exist, abort handling the passed URLs and exit this method.
        guard let url = URLContexts.first?.url else {
            return NSLog("No URL passed to open the app")
        }
        
        handleURL(url: url)
    }

Go ahead and build your app. Then, without closing your app, open the Safari app and type in celsiusapp://hostpart/my/path/?name=celsius&color=blue into the address bar and hit go. After you now tap on open, you should see the following output in the Xcode console:

host: hostpart
pathComponent 0: /
pathComponent 1: my
pathComponent 2: path
Query param name: celsius
Query param color: blue

Congrats, you have successfully handled an incoming URL!

This will also work when your app is launched after having been terminated. You just won't be able to see the output in the Xcode console, as your app disconnects from the Xcode debugger when it's closed. Open up the Console app by typing "Console" into the Spotlight search. Make sure your app is terminated. In the Console application, select your simulator or device and click on "Clear" to clear previous logs. Then open Safari in your simulator or on your device and type in celsiusapp://hostpart/my/path/?name=celsius&color=blue again and hit go. If you now filter for "PROCESS" in the Console application and type in the name of your application, you should see the above host, path components etc. printed to the logs.

While opted out of Scenes

If your app has not opted into scenes, as is the case for apps that support iOS versions < 13, you need to handle the incoming URL in the application(_:open:options:) method in AppDelegate.swift

We can use the same handleURL function as we used above. So the only thing we need to do is implement the delegate function and pass the URL to the handleURL function.

    func application(_ application: UIApplication,
                     open url: URL,
                     options: [UIApplication.OpenURLOptionsKey : Any] = [:] ) -> Bool {
        
        self.handleURL(url: url)
        return true
    }   

That's all. You can get more information about the URL from the options object, which we are not going to do at this point, however.

You can try opening the app from a URL in Safari again as we did before. It should log the same output as it did above. Unlike when working with Scenes as shown above, we can handle URLs both when the app was launched from a terminated state and when it was opened from the background or a suspended state with the same method.

LAUNCHING APPS WITH URL SCHEME

You can also open an app via a URL programmatically. Use the open(_:options:completionHandler:) method of UIApplication to do that.
Use the completion handler to be notified when the URL has been delivered successfully.

let url = URL(string: "celsiusapp://hostpart/my/path/?name=celsius&color=blue")
       
UIApplication.shared.open(url!) { (result) in
    if result {
       // The URL was delivered successfully!
    }
}

Note, if you want to try this out, you'd have to do it from another app rather than the one we have been working with in this article.

Alternative to URL Schemes

I have already mentioned Universal Links before in this article. Universal links are a more secure and sophisticated alternative to URL schemes. Apple recommends using Universal Links whenever possible.
If you do use URL schemes, make sure to validate URLs and limit the available actions incoming URL schemes may trigger. For instance, you should probably not allow incoming URLs to trigger destructive or mutating actions on the user's data.

How to opt-out

First you have to remove the "Application Scene Manifast" entry from Info.plist.

Next, remove the scene delegate class if there is one.

Then, remove all scene related delegate methods in your app delegate. Those methods will have the word scene in their names.

Also in your app delegate, add var window: UIWindow? if it's not already there.

That's it. If you've correctly followed these steps, your app should now work without using scenes, reverting back to the old lifecycle.

There are two ways of accomplishing this:

bundleInDebug

In your app/build.gradle file you should see a large commented out block that explains which settings you can set in the project.ext.react map inside your gradle file:

The one that is interesting to us is bundleInDebug: true.
Look for the project.ext.react map (should be right after the commented out block) in your gradle configuration file and add the bundleInDebug: true entry to the map:

project.ext.react = [
    ...
    
    //ADD THIS LINE 
    bundleInDebug: true
    
    ...
]

This tells gradle to actually bundle the JS code and assets and package those files into the APK instead of serving them up from the dev server.

If you try this out, you will notice that while your app now runs without the dev server it will still display yellowbox warning messages. This is because it is still a development build. If you want to make it a production build, which will have no warnings and will have a minified JS bundle, add the devDisabledInDebug: true entry to the project.ext.react map.

project.ext.react = [
    ...
   
    bundleInDebug: true
    
    //ADD THIS LINE
    devDisabledInDebug: true
    
    ...
]

Note: debug vs release refers to the Android build types, as specified in gradle, whereas development vs production affects the behaviour of the JS bundle.

When you now create an APK with ./gradlew assembleDebug or by running react-native run-android it will be a debug APK, bundled with the minified JS bundle and all assets,capable of running without the dev server.

react-native bundle

If, for some reason, you want or need to manually invoke the react-native bundle command to bundle your JS and your assets, the way to build a development-server-independent APK is as follows:

react-native bundle --dev false --platform android --entry-file index.js --bundle-output ./android/app/build/generated/assets/react/debug/index.android.bundle --assets-dest ./android/app/build/res/react/debug

Let's unpack what is happening there:

The bundle command is simply the command used to bundle the JS and the assets.

--dev false tells it to not bundle it using development mode, i.e. disable warnings and minify the bundle. This corresponds to the devDisabledInDebug: true setting above.

--platform android is self explanatory. Needs to be set, as the default is "ios".

--entry-file index.js is also quite self explanatory. If your entry file is named differently, then you should of course write that name there.

--bundle-output here is where it gets interesting. How do we know the path for the bundle output? In order for gradle to be able to find the bundle it must be in a path where gradle expects it and also be named the way gradle expects it.
This information can be found in the node_modules/react-native/react.gradle file.

Find the line where the variables jsBundleDir and resourcesDir are being defined and assigned values to.

buildDir is the android/app/build directory in your project and targetPath is either debug or release, depending on the build type of your build.

These are the paths where gradle expects to find the JS bundle and the assets to be packaged with the APK.

If, for some reason, you want to override those locations (or any other build settings), do not change them in the react.gradle file directly, but rather in your app level build.gradle file inside the project.ext.react map.

import styled from "styled-components";
import COLORS from "../../global/colors";


/*
100    Extra Light or Ultra Light
200    Light or Thin
300    Book or Demi
400    Normal or Regular
500    Medium
600    Semibold, Demibold
700    Bold
800    Black, Extra Bold or Heavy
900    Extra Black, Fat, Poster or Ultra Black
*/

export const Roboto10 = styled.Text`
        fontFamily: Roboto-Regular;
        fontSize: 10;
        fontWeight: normal;
        fontStyle: normal;
        lineHeight: 11;
        letterSpacing: 0;
        color: ${COLORS.purpleBrown};
`;

export const Roboto14 = styled.Text`
        fontFamily: Roboto-Regular;
        fontSize: 14;
        fontWeight: normal;
        fontStyle: normal;
        lineHeight: 24;
        letterSpacing: 0;
        color: ${COLORS.purpleBrown}
`;

export const Roboto16 = styled.Text`
        fontFamily: Roboto-Regular;
        fontSize: 16;
        fontWeight: normal;
        fontStyle: normal;
        lineHeight: 24;
        letterSpacing: 0;
        color: ${COLORS.purpleBrown}
`;

export const Roboto16Bold = styled.Text`
        fontFamily: Roboto-Regular;
        fontSize: 16;
        fontWeight: bold;
        fontStyle: normal;
        lineHeight: 24;
        letterSpacing: 0;
        color: ${COLORS.purpleBrown};
`;

This way of doing it is quite cumbersome because:

• you have to do a lot of writing.
• you always have to check whether a component with a given configuration already exists or not (as to not add duplicates).
• when you have to change the configuration, it might lead to unexpected UI changes in places you might not be aware of.

So recently I a started writing dynamically configurable text components.

/*
100    Extra Light or Ultra Light
200    Light or Thin
300    Book or Demi
400    Normal or Regular
500    Medium
600    Semibold, Demibold
700    Bold
800    Black, Extra Bold or Heavy
900    Extra Black, Fat, Poster or Ultra Black
*/

export type TextComponentConfig = {
    font: ?string,
    fontSize: ?number,
    lineHeight: ?number | ?string,
    fontWeight: ?number | string,
    fontStyle: ?number | string,
    color: ?string
}

const components = Object.create(null);

export default function TextComponents({
    font, fontSize, lineHeight, fontWeight, fontStyle,
}) {
    const key = `${font}_${fontSize}_${fontWeight}_${fontStyle}`;

    if (components[key]) {
        return components[key];
    }

    const TComp = styled.Text`
        fontFamily: ${font || ""};
        fontSize: ${fontSize || 16};
        fontWeight: ${fontWeight || "normal"};
        fontStyle: ${fontStyle || "normal"};
        lineHeight: ${lineHeight || fontSize || 16};
        letterSpacing: 0;
        color: ${COLORS.purpleBrown}
    `;
    components[key] = TComp;
    return TComp;
}

The TextComponents function takes an object that contains the configuration parameters for the desired text components. It then creates a key for that specific text component by simply stringing together all the passed parameter values into a key string. This key string is used to look up whether a component with that very same key has already been created and exists in the components object. If so, that component is returned. If not, we create a new component, save it in the components object and return it.

As you can see, I am not making use of all of the properties than can be used to style a Text component (for instance lineHeight, which should be trivial to add however.

Using TextComponents

The function can be used by passing the font configurations parameters as an object. Take a look at the following snippet to see how to dynamically generate and use a text component with the TextComponents function.

import React from "react";
import TextComponents from "./TextComponents";
const GreetingText = TextComponents({ font: "Oswald-Regular", fontSize: 18, color: COLORS.lightBlack, fontWeight: "bold", lineHeight: 25 });

export function HelloWorld(){
    return(
      <GreetingText>Hello World!</GreetingText>
    );
}

Code

The complete source code for the project can be viewed here.

I have only ever written one, also toy, VM before when I was working through the Nand2Tetris book and course some years back and had long forgotten some of the specifics, which is why this exercise was a good refresher.

You will notice that the code is in no way optimized, but it works, which is good enough for now.
Both memory and the registers are represented as UInt16 arrays. I could have gone with pointers to UInt16 values directly in memory, which probably would have been faster and more elegant.

Here are some interesting things I (re)learned while implementing this project.

Sign Extend

The LC-3 VM works with unsigned 16 bit integers. However, some of the instructions, such as the ST (store) instruction depicted below, call for arithmetic operations of an unsigned 16 bit integer with a another integer with fewer than 16 bits. The ST operation works by storing the contents specified by the register SR in the memory location specified by adding the program counter offset (PCOffset) bits 0 through 8 to the current value of the program counter (PC). The PC, much like all other registers in the LC8 machine is a 16 bit value, however, while the PCOffset is 9 bits wide.
To be able to go through with the addition of the two values, the PCOffset value will have to be sign extended. If the most significant bit of the PCOffset is 0, we simply fill up PCOffset with 0s to the left until it's 16 bits long. In case of a MSB of 1, PCOffset is filled up with 1s.
Sign extension of a value basically increases the number of bits of a binary number while preserving its sign (positive/negative).

Overflow addition in Swift

Unlike with the C programming language when adding two UInt16 integers in Swift (or any unsigned integers for that matter), there is no automatic overflow handling.
For instance the following code will give an EXC_BAD_INSTRUCTION error in Swift:

let n: UInt16 = UInt16(UINT16_MAX)
print(n + 5) //EXC_BAD_INSTRUCTION

In order to opt in to overflow behavior for unsigned integers, you have to use the overflow addition (or subtraction or multiplication) operator &+.

let n: UInt16 = UInt16(UINT16_MAX)
print(n &+ 5) //4

Terminal modes

A terminal's default behavior for stdin is to buffer and pre-process keyboard inputs until a new line \n is encountered and only then pass it on to the running program. This mode is called cooked or canonical mode.
To implement the checkKeyBoard() function for the VM I needed every individual key press to be passed on to my program without any buffering and waiting for a new line character to be entered.
This requires the terminal to be set to raw or non-canonical mode.
We can set a terminal's attributes by reading them out with tcgetattr() into a struct, modifying that struct and then passing that modified struct into tcsetattr().

To big endian

Writing this VM served as a welcome refresher on endianness. It reminded me that endianness refers to the ordering of individual bytes of an integer word (while endianness can refer to individual bits, this is exceedingly rare in practice).
LC-3 VM programs are big endian. Most modern CPU architectures use little endian byte ordering. In order for the VM to work correctly on little endian machines, we had to swap the endianness of every read in 16 bit word from big to little endian representation.

Memory mapped registers

I was reminded of the existence of memory mapped registers while implementing this project. These registers are, as the name implies, not available in the register table, but instead have special addresses in memory. These registers can be read from and written to by simply treating them as regular memory addresses.
In the LC-3 machine, the keyboard status register (KBSR) and the keyboard data register (KBDR) are two such memory mapped registers. The KBSR indicates whether or not a keystroke on the keyboard has been registered. The KBDR holds the value (in our case ASCII code) of the key that has been pressed. The registers are polled in every iteration of the the VM while loop to check for keystrokes.

Writing this VM has been a lot of fun and very educational. If you have the time I would definitely recommend writing one yourself to deepen your understanding of some low level hardware concepts.

For security, a user can only send signals to processes which they own, unless they are the superuser.

You use the kill command by supplying it with a process id of the process you wish to send the signal to and optionally a signal, in the form of a number or a name. The default signal used when no signal is specified is SIGTERM.

List signals

kill -l lists all the signals on your OS. On my MacBook Pro with Mojave installed this is the output of running kill -l.

1. SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
2. SIGTRAP 6) SIGABRT 7) SIGEMT 8) SIGFPE
3. SIGKILL 10) SIGBUS 11) SIGSEGV 12) SIGSYS
4. SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGURG
5. SIGSTOP 18) SIGTSTP 19) SIGCONT 20) SIGCHLD
6. SIGTTIN 22) SIGTTOU 23) SIGIO 24) SIGXCPU
7. SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH
8. SIGINFO 30) SIGUSR1 31) SIGUSR2

The mapping between numbers and signals can be different between Unix implementations.

Send a SIGTERM signal to a process

kill 64
will send a SIGTERM signal to the process with id 64. Notice how no signal number or name is specified. When that is the case, the default is to send the SIGTERM signal to the process.

Send a signal by number or name

To send a signal by number, type:

kill -9 64.
This will send the SIGKILL (see number to signal mapping above) signal to process with id 64. The SIGKILL signal will cause a process to terminate immediately. While for other signals it is possible for the processes to register signal handlers, for instance, to do some clean up before terminating, SIGKILL kills the specified process right away.
SIGSTOP is similar in as that can't be handled with a signal handler.

To send a signal by name, type:
kill -SIGQUIT 64 or kill -s SIGQUIT 64
This will send the, you guessed it, SIGQUIT signal to the process with id 64.
The SIGQUIT signal terminates the process and dumps the core before it does so.

Terminal signals

When you hit CTRL + C in your terminal, the signal sent to the current process is SIGINT. SIGINT asks the process to terminate.

For CTRL + Z it is SIGSTP. SIGSTP is the terminal equivalent to SIGSTOP. It suspends the process which can then be resumed at a later time with SIGCONT.

const book = {
    author: "Bobby B.",
    title: "Ladida"
}
const {author, title} = book;
console.log(author) // Bobby B.
console.log(title) // Ladida

How not to do it

However, sometimes you might need to destructure an object without declaring the identifiers on the left hand side as new variables, for instance, when those variables exist in the same scope and you can't redeclare the variables.

You might try to do something like this, which will give you a SyntaxError, as author and title have already been declared in the same scope:

let author;
let title;

const book = {
    author: "Bobby B.",
    title: "Ladida"
};

const {author, title} = book;

Since that didn't work, you might try something like in the following snippet. If you do, you will be met with a: "SyntaxError: Unexpected token =". This is because opening braces { at the beginning of a statement are interpreted as a block in JavaScript. And blocks cannot be assigned to.

let author;
let title;

const book = {
    author: "Bobby B.",
    title: "Ladida"
};

{author, title} = book;

Shadowing inside loops

Another example is when you loop through an array of items want to break the loop as soon as you encounter an item that holds a certain value.

Consider the following snippet. We have an array of books, consisting of an author and a title. We want to loop through it and assign the author and the title to the author and title variables that are declared before the loop, so that we can access those variables after the loop.

const books = [{}, {}, {}, {} ,{}, {author: "Bobby. B", title: "Ladida"}, {}, {}, {}, {} ,{}];

let author;
let title;

for(let book of books ){
    // destructure author and title out of book and if author is Bobby B. then break the loop.
}

Since the author and the title variables are declared outside of the for-of loop, we can destructure them inside the loop by declaring new author and title variables with the const or the let keyword and thus shadowing the variables outside of the loop.

This is not quite what we want, however. Since we declared these two variables inside the loop now, we won't be able to access them after the loop.
When logging the variables we get undefined for both of them, as the destructured variables, declared inside the loop, have gone out of scope once the loop has finished.

Note, that if you used var to declare the destructured variables inside the loop you would once again get a "SyntaxError: Identifier 'author' has already been declared". This is because var variables are function level scoped in JavaScript, whereas const and let variables are block scoped.

Don't use var!

const books = [{}, {}, {}, {} ,{}, {author: "Bobby. B", title: "Ladida"}, {}, {}, {}, {} ,{}];

let author;
let title;

for(let book of books ){
    const {author, title} = book;
    if(author === "Bobby. B"){
        break;
    }
}
console.log(author) // undefined
console.log(title) // undefined

The right way to do it

As mentioned above, when braces { appear as the beginning of a statement, they are interpreted as a block. When braces appear at later point in a statement, such as when beginning the statement with const, let or var (don't do it!), they are interpreted as an object.
So all we have to do is make it so that the braces do not appear first in the statement, while also not using const, let or var (seriously, don't).

How?
Wrap the entire line where the destructuring happens in parentheses ().

For our first code snippet we will get the following:

let author;
let title;

const book = {
    author: "Bobby B.",
    title: "Ladida"
};

({author, title} = book);

And this is what our second snippet looks like after wrapping the desctructuring line in parentheses:

const books = [{}, {}, {}, {} ,{}, {author: "Bobby. B", title: "Ladida"}, {}, {}, {}, {} ,{}];

let author;
let title;

for(let book of books ){
    ({author, title} = book);
    if(author === "Bobby. B"){
        break;
    }
}
console.log(author) // undefined
console.log(title) // undefined

When wrapping the entire line in parentheses, make sure to end the previous line with a semicolon. Otherwise, it might trigger a function invocation!

If you have ever been confused about all the different kinds of prototypes in JavaScript, you are not alone. This article is an overview and explanation of the different kinds of prototypes and their purposes in JavaScript.

[[Prototype]]

In the ECMAScript specifications double brackets denote internal properties and are, according to the specs, not part of the ECMAScript language. This means that those internal properties are not accessible by the objects that contain them.

[[Prototype]] is an internal property on all JS objects that points to the object's prototype. Every JS object has an internal [[Prototype]]. This goes for for objects created with object literals, those created with the new keyword and also for those created with Object.create(). Further, even function constructors have an internal [[Prototype]].

__proto__

Since [[Prototype]] is an internal property it was never meant to be accessible by developers, according to the ECMA specs. At some point, however, browser vendors and other environments started giving access to the internal [[Prototype]] object via the __proto__ property.
This means that __proto__ and [[Prototype]] refer to the same thing.
__proto__ is simply a way to access the internal [[Prototype]] in some JS environments.

The internal [[Prototype]] is a regular JS object and thus also has an internal [[Prototype]] and so on. This goes all the way down to Object.prototype. The internal[[Prototype]] of Object.prototype is null. This is called the prototype chain. More on that later.

.prototype

The .prototype property only exists on function constructors! When you define a function, the constructor is given an almost empty .prototype object for free. The only property on this object is .constructor, which points back to the function constructor, i.e. .prototype has a property .constructor and vice versa.

When you create a new object with the new keyword, its internal[[Prototype]] is set to the .prototype of the function constructor that was used to create the object.

Object creation prototype chain

Let's look at how the internal [[Prototype]] object is set when creating an object with the new keyword, as an object literal and with Object.create().

new keyword

When you create a new object with the new keyword, that object's internal [[Prototype]] is set to the constructor function's .prototype

function Car(){}
const mCar = new Car();
mCar.__proto__ === Car.prototype; // true

Object literal

When you create a new object with the object literal syntax the object's internal [[Prototype]] is set to Object.prototype.

const obj = {};
obj.__proto__ === Object.prototype; // true

Object Create

When you create a new object with Object.create(), the internal [[Protoype]] of the created object is set to the object passed in as the first argument to Object.create().

const car = {
    wheels: 4
};
const mCar = Object.create(car);
mCar.__proto__ === car // true

Prototype chain

Since the internal [[Prototype]] object is simply that, an object, it too has an internal [[Prototype]], which in turn, yada yada yada.
This leads to a prototype chain.

If a prototype is not specified for an object explicitly, then the default value for __proto__ is taken: Object.prototype.
Object.prototype itself also has a __proto__, which is the final link of the chain and is set null.

If a property or method isn't found on an object instance, the prototype chain is traversed. The first found property/method with the same name is used. If none is found in the entire chain, all the way down to Object.prototype, undefined is returned.

Properties in the prototype chain are called 'inherited properties' as opposed to properties on the instances themselves which are 'own properties'.

Template literals in JavaScript are basically regular strings on roids. The syntax for writing them is with backticks `` instead of regular string quotes. You can place expressions into those template literals which will be evaluated and replaced with the resulting values of those expression.

const name = 'Celsius';
`My name is ${name}. What's yours?` // My name is Celsius. What's yours?

Here is how the evaluation process of a template literal works:
The template literal is broken down into an array of strings and a list of variables. In the example above the array of strings would be [ 'My name is ', '. What\'s yours?' ] whereas the list of variables would consist only of the evaluated value of the name variable, which is "Celsius".

Then, this array of strings and the list of evaluated values is passed to a function which can concatenate all those strings and return the phrase "My name is Celsius. What's yours?" That is in fact what the default function for template literals does. It simply concatenates the strings in the array, inserting the values of the evaluated expressions between them. A sample implementation of this default template literal function could look like this:

function defaultTemplateLiteralFunction(strings, ...values){
	return strings.reduce((acc, v, i) => {
		acc += v;
		acc += values[i] || '';
		return acc;
	}, '');
}

What this function does is simply concatenate the values from the strings array and the list of evaluated values alternatingly, starting with the list of strings.

Tagged Templates

JavaScript let's you define your own function to process the arguments extracted from the template literal. If you write a function right before the template literal this function will be used to process the arguments extracted from the template literal by JavaScript. This is called a tagged template.

function tag(strings, ...values) {
	return `Hey ${values[0]}, nice to meet you. I am a tagged template :)`;
}

tag`My name is ${name}. What's yours?`; // Hey Celsius, nice to meet you. I am a tagged template :)

The above syntax can be thought of as invoking the tag function passing it the template literal (already processed into an array and values) as arguments.

Note, that tagged templates do not have to return strings! You can return any kind of value you like from your tagged templates. Yes, even a React component, which is really just a function anyway.

Using Tagged Templates

You can use tagged templates anywhere you want to have more control over template literals and return different values based on the contents of the template literal.

One very popular library that uses template literals is the styled-components library for React and React Native applications. To create a simple styled h1 component you could write something like the following:

const fontSize = calculateFontSize();
RedCenteredText = styled.h1`
	color: red;
	text-align: 'center;
	font-size: ${fontSize};
`

In this case styled.h1 is a tagged template function, receiving the contents of the template literal. The template function parses the received CSS, replaces the placeholder variables with the appropriate values and returns an H1 React component with the given styles.

RedCenteredText is a React component which you could then use in your markup just like any other React component such as:

<div>
	<RedCenteredText/>
</div>

So far, we've only ever passed simple variables to be evaluated by the template literal. However, functions can also be passed as values to the template literal. If you have worked with the styled-components library before you will probably be familiar with how the following code snippet works:

RedOrWhiteCenteredText = styled.h1`
	color: ${props => props.error ? 'red', 'white'};
	text-align: 'center;
	font-size: ${fontSize};
`

What happens here is that we are not only passing a variable but also a function to the template literal. The function processing the template literal will now return an H1 React component with either red or white text color depending on whether or not the error prop passed to that component is true.

Styled HTML elements

Let's try to work our way towards writing a tag function that takes a template literal with parametrized CSS and returns a React component whose styles adapt to the props passed to it.

Here is how you could write a sample styled.div tag function that takes in a string of CSS styles and returns <div> element with those given styles as inline styles.

const styled = {
    div: (strings, ...values) => {
        const styles = strings[0]
        .trim()
        .replace(/\n/gi, "")
        .replace(/\s\s/gi, "");        
        return `<div style="${styles}"></div>`;
    }
}

const StyledDiv = styled.div`
    background-color: red;
    width: 50px;
    height: 50px;
    text-align: center;
`;

console.log(StyledDiv) 
//<div style="background-color: red;width: 50px;height: 50px;text-align: center;"></div>

We remove all unnecessary whitespaces by trimming, replacing new lines and replacing double spaces with single spaces and then simply pass the resulting value as the contents of the style attribute to a <div>.

Now, what if we want to pass variables to the template literal? We make use of our defaultTemplateLiteralFunction defined above to preparse the parametrized styles into a string of temporary styles, which then undergoes the same treatment as the styles from our previous example:

function defaultTemplateLiteralFunction(strings, ...values){
	return strings.reduce((acc, v, i) => {
		acc += v;
		acc += values[i] || '';
		return acc;
	}, '');
	
}

const styled = {
    div: (strings, ...values) => {
        const tempStyles = defaultTemplateLiteralFunction(strings, ...values);
        const styles = tempStyles
        .trim()
        .replace(/\n/gi, "")
        .replace(/\s\s/gi, "");;
        return `<div style="${styles}"></div>`;
    }
}

const red = "green";
const size = "75px";

const StyledDiv = styled.div`
    background-color: ${red};
    width: ${size};
    height: ${size};
    text-align: center;
`;

console.log(StyledDiv)
// <div style="background-color: green;width: 75px;height: 75px;text-align: center;"></div>

Creating HTML elements with inline styles from tagged template literals is fun and all but doesn't really seem all that useful, as there is no way to use the generated HTML without some extra effort.

Styled React components

Now let's figure out how to return a fully-fledged React component from a template literal function.

import React, { Component } from "react";

/**
 * @function parseStyles
 * Parses a string of inline styles into a javascript object with casing for react
 * Source: https://gist.github.com/goldhand/70de06a3bdbdb51565878ad1ee37e92b
 *
 * @param {string} styles
 * @returns {Object}
 */
const parseStyles = styles =>
  styles
    .split(";")
    .filter(style => style.split(":")[0] && style.split(":")[1])
    .map(style => [
      style
        .split(":")[0]
        .trim()
        .replace(/-./g, c => c.substr(1).toUpperCase()),
      style.split(":")[1].trim()
    ])
    .reduce(
      (styleObj, style) => ({
        ...styleObj,
        [style[0]]: style[1]
      }),
      {}
    );

const styled = {
  div: (strings, ...values) => {
    return function(props) {
      function defaultTemplateLiteralFunction(strings, ...values) {
        return strings.reduce((acc, v, i) => {
          acc += v;
          if (!values[i]) {
            acc += "";
            return acc;
          }

          acc += typeof values[i] === "function" ? values[i](props) : values[i];
          return acc;
        }, "");
      }

      const tempStyles = defaultTemplateLiteralFunction(strings, ...values);
      const styles = tempStyles.trim().replace(/\n/gi, "");
      if (!styles) {
        return null;
      }

      let parsedStyles = parseStyles(styles);
      return React.createElement(
        "div",
        {
          ...props,
          style: parsedStyles
        },
        "Hello"
      );
    };
  }
};

const red = "red";
const size = "100px";

const StyledDiv = styled.div`
  background-color: ${red};
  width: ${props => (props.small ? size : size * 2)};
  height: ${props => (props.small ? size : size * 2)};
  text-align: center;
`;

class App extends Component {
  render() {
    return (
      <div className="App">
        <StyledDiv small />
        <p className="App-intro">
          To get started, edit <code>src/App.js</code> and save to reload.
        </p>
      </div>
    );
  }
}

export default App;


// If you take away the `small` prop it doesn't work since the multiplication of 100px * 2 returns NaN and I didn't feel like implementing px value times integer multiplication for this proof of concept.

So what's happening here? The parseStyles function takes a string of inline styles and parses them into a JS object with the correct casing (camelCase) so that these styles can be used within a React component. The code for this was taken from here.

Our implementation for a div styled component now returns a React component, which is simply a function that returns a React element. Inside this function, we define defaultTemplateLiteralFunction with a slightly different implementation than above. Defining the function inside the functional component is done, so that the function captures the props which are passed to the React functional component.

When we now call

styled.div`
    style1:...
    style1:...
    etc.`

the passed styles are first processed just as before by concatenating the them into a single string, replacing the parametrized values. The crucial difference in this implementation of the defaultTemplateLiteralFunction is that if we detect a parametrized value to be a function, we call that function, passing it the props of the functional component.

At this point all parametrized values have been replaced and we have a string of styles in tempStyles. All that's left to is turn this string into a JS object so that it can be used as a React style object. The parseStyles function does just that.

Now that we have a proper JS style object we can create our React Element, passing it the parsed styles and returning it from our functional component.
Et voilá, we have a poor man's implementation of div styled-components.

About React Native Navigation

React Native Navigation is a native navigation library based on the underlying native navigation of the platform and is not a JavaScript based navigation solution like most other navigation libraries for React Native.

Installing React Native Navigation

To install React Native Navigation simply follow the installation instructions give here for Android or here for iOS.
Note, that this article was written using React Native Navigation version 1!

Getting Started

To start an app with React Native Navigation you have to call either the static startTabBasedAppor the static startSingleScreenApp with the appropriate params object. We will be using the startTabBasedApp method for our drawer navigator example, since it naturally comes with support for tabs.

Simple Tab

To keep this simple and focused on the the drawer menu, we will be showing empty screens for every tab, with nothing but the screen title in the navigation bar. Let's create a Tab component right in our index.js file which will serve as the screen component to be shown for all drawer tabs.

const Tab = () => {
	return(
		<View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
			<Text>Tab Screen</Text>
		</View>
	)
}

Registering Screens

RNN requires you to register screens before showing them on screen. For that we create a registerScreens() function.

In that function we will register the components for all the screens we want to show on in our app. The RNN docs recommend choosing names which will be unique within the entire app, as your screens might end up being bundled with other packages. It is recommended to use the following naming convention packageName.screenName. So let's create a constant packageName and the registerScreens() function in our index.js file.

import { Navigation } from 'react-native-navigation';

const packageName = 'com.rnplayground';

function registerScreens(){
	Navigation.registerComponent(`${packageName}.Cart`, () => Tab );
	Navigation.registerComponent(`${packageName}.Wishlist`, () => Tab );
	Navigation.registerComponent(`${packageName}.Deals`, () => Tab );
	Navigation.registerComponent(`${packageName}.Browse`, () => Tab );
	Navigation.registerComponent(`${packageName}.SettingsTab`, () => Tab );
	Navigation.registerComponent(`${packageName}.DrawerScreen`, () => DrawerNavigatorContainer );
}

Defining Tabs

The Navigation.startTabBasedApp method takes an object which has a tabs property, which excpects an array specifying all the tabs and their properties.

Let's create a function called getTabConfig() which returns the this tabs array.

function getTabConfig() {
	const tabs = [
		{
			screen: `${packageName}.Cart`,
			title: 'Shopping Cart',
			iconName: 'shopping-cart',
			iconColor: 'yellow',
			icon: require('./image.png'),
			navigatorStyle: {
				tabBarHidden: true,
			},
		},
		{
			screen: `${packageName}.Wishlist`,
			title: 'Wishlist',
			iconName: 'favorite',
			iconColor: 'red',
			icon: require('./image.png'),
			navigatorStyle: {
				tabBarHidden: true,
			},

		},
		{
			screen: `${packageName}.Deals`,
			title: 'Deals',
			iconName: 'money-off',
			iconColor: 'orange',
			icon: require('./image.png'),
			navigatorStyle: {
				tabBarHidden: true,
			},

		},
		{
			screen: `${packageName}.Browse`,
			title: 'Browse',
			iconName: 'search',
			iconColor: 'green',
			icon: require('./image.png'),
			divider: true,
			navigatorStyle: {
				tabBarHidden: true,
			},
		},
		{
			screen: `${packageName}.SettingsTab`,
			title: 'Settings',
			iconName: 'settings',
			iconColor: 'grey',
			icon: require('./image.png'),
			navigatorStyle: {
				tabBarHidden: true,
			},
		},
	];

	return tabs;
}

If you take a look at the documentation for startTabBasedApp here, you'll notice that the iconName, iconColor and the divider (in the Browse tab object) properties are nowhere to be found. That's because they are not part of RNN. I just added those myself, because we'll need those values later on.

The screen property specifies which component will be shown when you tap on that tab. The title property defines the name that will show up in the navigation bar. While we won't be using the icon attribute, it is required by RNN for every tab object. We just give it the value of a random image.png image, which is in the same directory as the index.js file.

The navigatorStyle object allows you to style your navigator. We only make use of the tabBarHidden attribute for now, by setting it to true in every tab.

Starting the App

Now that we've defined our tabs it's almost time to start the app for the first time. We're close, I promise. Let's create a function called startApp() in the index.js file in which we register the screens, get the tab configurations and then call Navigator.startTabBasedApp(), passing the tabs and a few other options.

The drawer property let's us specify a drawer with all its properties and settings. We want a left drawer, which is why we define the left property of the drawer object. In it we define the screen, which will be rendered as the left drawer and also get to define props that will get passed to the drawer when the app is started. The contents of the passProps object will be available as regular props in the drawer component. We pass the tabs array, an activeIndex attribute set to 0 and the profileInfo object.

In order to make the tab bar not show at the bottom of the screen, we also set the tabBarHidden property of the tabStyle object in the drawer object to true.

function startApp() {
  
	registerScreens();
    
	const tabs = getTabConfig();

	const profileInfo = {
		firstName: 'Celsius',
		lastName: 'W.',
		imgSource: require('./image.png')
	}
    
	Navigation.startTabBasedApp(
		{
		tabs: tabs,
		drawer: { 
			left: {
			screen: `${packageName}.DrawerScreen`, // unique ID registered with Navigation.registerScreen
			passProps: {
				tabs: tabs,
				activeTabIndex: 0,
				profileInfo: profileInfo

			},
			fixedWidth: 800,
			}
		},
		tabsStyle:{
			tabBarHidden: true,
		}
		},
	);
  
  }

DRAWERNAVIGATOR CLASS

Before we move on to the DrawerNavigatorContainer, the centerpiece of this tutorial, let's first take a look at two other components that we will use inside the DrawerNavigatorContainer: the DrawerProfileContainer and the DrawerItem component.

The DrawerProfileContainer component houses the profile image and the name of the user. The DrawerItem component is a pressable component representing all the tabs that we can navigate to. It has a icon and a label.

export default DrawerProfileContainer = (props) => {

    const {source, firstName, lastName, containerStyle} = props;
    const iconProps = source ? {source: source} : {icon: {name: 'account-circle'}}

    return(
        <View style={[styles.container, containerStyle]}>
            <Avatar
                width={80}
                height={80}
                activeOpacity={0.7}	
                rounded={true}
                containerStyle={styles.avatar}
                {...iconProps}
            />
            <Text
                style={styles.nameText}>
                {firstName} {lastName}
            </Text>
        </View>
    );


}

export default DrawerItem = (props) => {
    const {label, iconName, iconColor, isActive} = props;
    const containerStyles = isActive ? [styles.container, styles.containerActive] : [styles.container]
    return (
        <TouchableOpacity onPress={props.onPress}
            underlayColor='blue'>
            <View style={containerStyles}>
                {isActive && 
                    <View style={styles.leftBar}/>
                }

                <Icon name={iconName}
                    color={iconColor || 'white'}
                    size={24}
                    containerStyle={styles.icon}
                />
                <Text style={styles.label}>
                    {label}
                </Text>
            </View>
        </TouchableOpacity>
    );
}

Following is the code for the DrawerNavigationContainer component. This is the component that describes the look and behavior of the drawer.

In the render() method we return DrawerProfileContainer. We also iterate over the tabs prop that we passed via the passProps when we called Navigation.startTabBasedApp() above. From each item in that array we create a DrawerItem element, passing the navigationItemPressed() method as the onPress prop. When a DrawerItem receives a press, the navigator is told to switch to the tab specified by the DrawerItems's index and then toggle the drawer to close it. We also have to set our activeTabIndex state to the new index, which is exactly what we do.

You'll notice that there is also a Divider component that we render after the DrawerItem if the divider attribute on the current tab is a truthy value. What gives? If you take a look at the 4th tab in the tabs array in getTabConfig you'll see that is has a divider property. This is not a property provided by React Native Navigation, but one that I added so that when I rendered the drawer items, I could tell the DrawerNavigationContainer to render a divider after every DrawerItem component associated with a tab with a truthy divider property.

While we're on the subject of properties not provided by React Native Navigation, it should also be mentioned that the iconColor and iconName properties are also not from React Native Navigation. I added those, so that I could tell the DrawerItems which icons to render in which colors next to the labels. The icons are material icons from the react-native-elements library.

export default class DrawerNavigationContainer extends React.Component {

        state = {
            activeTabIndex: 0
        }

        navigationItemPressed = (route, index) => {
            action(`Should go to screen ${route.label} and close drawer.`)

            this.props.navigator.switchToTab({
                tabIndex: index,
            });
            this.props.navigator.toggleDrawer({
                side: 'left',
                to: 'closed',
                animated: 'true',
            });

            this.setState({
                activeTabIndex: index
            });
        }

        render(){
            const {tabs, profileInfo} = this.props;
            const {imgSource, ...rest} = profileInfo;

            if (!tabs) {
                return null;
            } else {
                return (
                    <View style={styles.container}>

                        <DrawerProfileContainer
                            source={imgSource}
                            {...rest}

                        />

                        <View style={styles.navigationContainer}>
                            {tabs.map((route, index) => {
                                const navigationLabel = route.title;
                                const navigationIconName = route.iconName;
                                const iconColor = route.iconColor;

                                return (
                                    <React.Fragment key={route.screen}>
                                        <DrawerItem
                                            label={navigationLabel}
                                            iconName={navigationIconName}
                                            isActive={this.state.activeTabIndex === index}
                                            iconColor={iconColor}
                                            onPress={() => {this.navigationItemPressed(route, index)}}
                                        >
                                        </DrawerItem>
                                        {route.divider && <Divider style={styles.divider} /> }
                                    </React.Fragment>
                                );
                            })}
                        </View>
                    </View>


                );
            }	

        }
    }

That's it. You should now have a drawer navigator if you compile and run the code on a device or an emulator.

You can check out the code for this article on github here.

If you have any questions or comments, get in touch via twitter or shoot me an email.

Support for Babel 7 and optional chaining

With React Native 0.56 comes support for Babel 7. If you are a Swift developer you will probably already be familiar with optional chaining.
Optional chaining allows you to access nested properties of an object without having to worry about undefined intermediate objects.

Let's say we have an object like this:

const house = {
	apartment: {
		tenant: {
			name: 'Peter'
		}
	}
}

Without optional chaining we would have to write something like this to access the nested name property of the house object:

let name = "";
if(house && house.apartment && house.apartment.tenant && house.apartment.tenant.name){
	name = house.apartment.tenant.name
}

Now with optional chaining we can try to access the name of the tenant without having to resort to querying each nested subproperty of house for undefined by simply writing:

const name = house?.apartment?.tenant?.name;

This line of code means:

If house is not undefined, evaluate house.apartment if house.apartment is not undefined evaluate house.apartment.tenant and if house.apartment.tenant is not undefined evaluate the value of house.apartment.tenant.name and assign it to name.

You can also mix optional chaining with normal chaining such as

const name = house?.apartment.tenant?.name;

This line means:

If house is not undefined, evaluate house.apartment and if house.apartment.tenant is not undefined, evaluate and assign the value of house.apartment.tenant.name to name.

Optional chaining is some nice syntactical sugar that allows you to write less code when accessing nested properties of an object. It also works with functions:

function identifyYourself() {
	return 'I am a function'
}

identifyYourself?.() // returns 'I am a function'

Flex wrap-reverse

Up until now flexWrap: wrap-reverse hadn't been implemented in React Native. flexWrap let's us specify wrapping behavior of flex elements. The default is nowrap. This means that when the elements are bigger than the row (or column) in which they are aligned, they will shrink according to their flex values without wrapping into the next row.
| 1 || 2 || 3 |

Specifying wrap tells Flexbox to wrap the elements into the next row (or column) if they are too big, so that they can retain their original sizes.
| 1 || 2 |
| 3 |

The wrap-reverse value is similar to wrap as it wraps the elements to the next row (or, yes you guessed it, column). However, on top of wrapping to the next column (or row; see what I did there? 😁), it also reverses the direction from which the elements are wrapped. Or more precisely in Flexbox parlance: 'cross-start and cross-end are swapped.
| 3 |
| 2 || 1 |

• Image.defaultSource property on Android
  • Allows you to set a local placeholder image while loading a remote image. This had already been implemented in iOS.
• Image.resizeMode=repeat on Android
  • Implements the repeat value for the resizeMode prop for the Image component. This also already existed on iOS.
• From now on the minimum required version of Node will be version 8. With this change trailing commas, which Prettier adds to function parameter lists, are now allowed.
• Xcode 9 and iOS 9 will now be the the minimum required versions for working with React Native 0.56
• Android projects are now compiled with the SDK 26.

Other noteworthy updates

• Image.defaultSource property on Android
  • Allows you to set a local placeholder image while loading a remote image. This had already been implemented in iOS.
• Image.resizeMode=repeat on Android
  • Implements the repeat value for the resizeMode prop for the Image component. This also already existed on iOS.
• From now on the minimum required version of Node will be version 8. With this change trailing commas, which Prettier adds to function parameter lists, are now allowed.
• Xcode 9 and iOS 9 will now be the the minimum required versions for working with React Native 0.56
• Android projects are now compiled with the SDK 26.

First-class function

Programming languages that support first-class functions allow functions to be passed as arguments to other functions and returned as values from them. First-class functions can also be assigned to variables. In essence, a language supports first-class functions if it treats functions as regular values. That’s really all there is to first-class functions. Pretty simple right?

Here are some examples of what you can do in languages that support first-class functions:

//Declare a function that takes a variable of type `Function` as a parameter
function myFunction(b: Function)
//Return a function return value from another function
function myFunction() {
…

return function(){
	…
}

}
//Assign a function to a variable
var f = function () {…}

The most common example of the usefulness of first-class functions is the map() function. The map() function takes some collection c and a function f as parameters. The function f in turn takes an element of the same type as the elements contained in the collection c (It can also take an index and other arguments in some cases). The map() function then returns a new collection d which is simply the result of applying the function f to every element of the original collection c. Other common examples for first class functions are reduce() and filter().

Higher-order function

Higher-order functions are simply functions that take one or more functions as arguments or return a function as a result (the function has to do at least one of those things to be considered a higher-order function). A function that does neither of those things is called a first-order function (not to be confused with first-class function!).
The concept of a higher-order function also exists in Mathematics, where the differential operator is a higher-order function, as it accepts a function and returns it's derivative, which is also a function.

function higherOrderFunction(a: Function) {
…
return function() {…}

Closures

A Closure is a type of first-class function. It is a function that captures or closes over its enclosing lexical scope. What does that mean? It means, that if you define a function and use variables inside that function that you have declared somewhere outside of that function, a closure will hold on to the references that point to those values, so that they still exist and can accessed even when the enclosing scope in which they where first declared no longer exists. Variables declared within the scope of the nested function are also called bound variables, while variables declared outside of the scope are free variables.

What's the point?

This can be useful when you define a nested function within a function and return that nested function as return value of the outer function assigning it to a variable. Once the outer function has returned, it will be gone along with all its declared variables. But what about the returned nested function that was assigned to a variable? That function will still have access to the values of the variables declared in the outer function, even though the outer function is gone. This is referred to as capturing those variables or closing over them, hence the name.

But how?

The way you can picture a closure in memory, is as a struct or an object holding references over which it closed and also including a function or a pointer to the function code. Wikipedia puts it well by stating that a closure is a ‘function together with an environment’.

When a closure is created, it stores references to all the free variables of its enclosing scope which it needs; sort of like a snapshot. This kind of makes sense for global variables which aren't declared in functions, but what about variables inside functions, which live on the stack. Shouldn't they cease to exist as soon as the enclosing function returns and its frame is popped from the stack? Well, languages with support for closures don't (usually) implement the call stack with an actual stack data structure. Instead, the call stack is implemented as a linked list on the heap (go figure). When a function returns, its node is removed from the list. If a closure has any references to variables on any frame, it simply keeps a reference to the node in question.

To make everything clearer, let’s look at an example:

function outer(a) {
return function increment() {
++a;
}
}

The outer function takes one argument and simply returns an inner function. The only thing the inner function does is to increment the value of the outer functions only parameter a. As soon as the outer function is called and its return value is assigned to incrementFromTen a closure is created, capturing a reference to the outer functions argument, which in this case happens to have a value of 10. Repeatedly calling incrementFromTen() will increment the captured value of a which has been captured by the closure, even though outer() has long returned.

Lambdas

A lambda is simply a function an anonymous function. Lambdas are often used as one off function arguments for higher-order functions.

Anatomy of an Index

• An index is pure redundancy. Just like the index in a book where everything in the book is listed and refers to the page on which you find it.
• A node consist of the value of the indexed column and the row id of the record.
• An index entry points to the location of the entry of the in the table, in which rows are completely unsorted, by means of row id.
  • Row is actually the physical location of the row inside that table (which is simply a file or several). It is the fastest way to locate that row (even faster than primary key, since primary key is nothing more than an index itself.)
• An index is a B-Tree (not always, there are also other indexes) with the leaf nodes connected as a doubly linked list.
  • The B-Tree can be searched by tree traversal and then the doubly linked list must be walked down by visiting one element after another.
• The keys of the leaf node elements are the values of the colums that is being indexed.

Slow Indexes

• Index traversal has 3 steps:
  • 1 tree traversal
  • 2 following leaf node chain
  • 3 accessing table data
• First ingredient to slow index is the leaf node chain, where the database must not only traverse the B-tree but then also must walk through all the leaf nodes in the linked list to see if there are more matching entries.
• Second ingredient is accessing the table. The actual corresponding table data to a leaf node is usually scattered across many table blocks. That means, for every hit, there is a table access.

Three ways of accessing and index:

• Index Unique Scan: Performs tree traversal only. Used if there is a unique constraint in the query making sure that only one entry will match
• Index Range Scan: Tree traversal and then follows the leaf node chain to find all matching entries. Used if multiple entries could match the query.
  • Can potentially read large parts of an index. Makes the query slow if many entries will have to be accessed with table access afterwards.
• Table Access by Index RowId: Retrieves the actual row from table. This is usually done for every matched entry after an index scan (the ones above) operation.

Since we use Realm for persistent storage in the app, which offers AES encryption with a 32 byte key, I chose to also use the same for encrypting non-database data such as user images and attachment files.

We're using React Native to create the app, which is why I hoped to find a preexisting React Native library that I could use. Unfortunately I couldn't find anything that actually worked the way I needed it to work, so I decided to write my own native module. Using a plain JavaScript crypto implementation was also not an option, as those are typically very slow, which would be problematic as there is a fair amount of encrypting and decrypting of data in the app.

Native Java code

These are the two methods for encrypting and decrypting a Base64 String input using the spongycastle crypto library.

@ReactMethod
    public void getRandomIv(Promise promise){
        SecureRandom rng = new SecureRandom();
        byte[] ivBytes = new byte[16];
        rng.nextBytes(ivBytes);
    String ivBase64 = Base64.encodeToString(ivBytes, Base64.NO_WRAP);
    promise.resolve(ivBase64);
}

@ReactMethod
public void encryptSpongy(byte[] key, String clearText, String ivBytesBase64, Promise promise)
{
try
{
byte[] clear = clearText.getBytes("UTF-8");
byte[] ivBytes= Base64.decode(ivBytesBase64, Base64.NO_WRAP);
        PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new AESEngine()));

        cipher.init(true, new ParametersWithIV(new KeyParameter(key), ivBytes));
        byte[] outBuf   = new byte[cipher.getOutputSize(clear.length)];

        int processed = cipher.processBytes(clear, 0, clear.length, outBuf, 0);
        processed += cipher.doFinal(outBuf, processed);

        byte[] outBuf2 = new byte[processed + 16];        // Make room for iv
        System.arraycopy(ivBytes, 0, outBuf2, 0, 16);    // Add iv
        System.arraycopy(outBuf, 0, outBuf2, 16, processed);    // Then the encrypted data

        final String encryptedB64 = Base64.encodeToString(outBuf2, Base64.NO_WRAP);

        //System.out.println(encryptedB64);

        promise.resolve(encryptedB64);

        //return encryptedB64;
    }
    catch(Exception e)
    {
        e.printStackTrace();
    }
}

@ReactMethod
public void decryptSpongy(byte[] key, String encryptedBase64, Promise promise)
{
try
{
final byte[] encrypted = Base64.decode(encryptedBase64, Base64.NO_WRAP);
        PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new AESEngine()));
        byte[] ivBytes = new byte[16];
        System.arraycopy(encrypted, 0, ivBytes, 0, ivBytes.length); // Get iv from data
        byte[] dataonly = new byte[encrypted.length - ivBytes.length];
        System.arraycopy(encrypted, ivBytes.length, dataonly, 0, encrypted.length   - ivBytes.length);

        cipher.init(false, new ParametersWithIV(new KeyParameter(key), ivBytes));
        byte[] clear = new byte[cipher.getOutputSize(dataonly.length)];
        System.out.println(cipher.getOutputSize(dataonly.length));
        int len = cipher.processBytes(dataonly, 0, dataonly.length, clear,0);
        len += cipher.doFinal(clear, len);


        final String decryptedString = new String(clear).substring(0, len);
        System.out.println(decryptedString);

        promise.resolve(decryptedString);


        //return decryptedString;
    }
    catch(Exception e)
    {
        e.printStackTrace();
    }
}    

The getRandomIV() method simply generates a random 16 byte initialization vector (IV) for the AES cipher and returns it as a Base64 encoded string.

In the encrypt() method
new PaddedBufferedBlockCipher(new CBCBlockCipher(new AESEngine())) means that we want to use the CBC mode of the AES cipher with padding. The padding mode used by default is PKCS7.
In the following lines the cipher is applied to the byte array of the input string and written into outBuf, after which the initiazation vector and the cipher are both copied into outBuf2. Finally, the cipher is encoded into a Base64 string and resolved as the result of a promise.

The decrypt() method simply reverses what happend in the encrypt() method, as AES is a symmetric cipher. Since the method expects the Base64 representation of the cipher instead of the actual cipher, we first have to decode it to retrieve the byte array on which the decryption algorithm will operate. Next we extract the initialzation vector and the encrypted data into separate byte arrays. After that, the same approach is used for decrypting the data that was used for encrypting it. The decrypted cleartext is stored in the clear variable.

Since we're using padding and AES is a block cipher which works on blocks of 16 bytes, the resulting cipher and also the cleartext obtained from decrypting will always be a multiple of 16 bytes.
This is why we have to extract the original cleartext in the decrypt() method from the result of applying the algorithm to the cipher. This is what happens here:
new String(clear).substring(0, len);. The len variable is the amount of bytes in the resulting cleartext which are not padding.

Takeaways and things I (re)learned in the process of implementing this module

• AES is a block cipher. This means it takes a plaintext of x bytes and encrypts it in blocks of y bytes. The resulting cipher will have a size that is a multiple of the blocksize y.
• AES requires a random initialization vector with the same size as the blocksize.
• In AES the block size is 16 bytes.
• If the last block of data is less than 16 bytes long it has to be padded, so that the algorithm can work with 16 bytes.
• The size of a cipher from a plaintext with length x is calculated as (x/16 +1)*16 (the division is an integer division).
  • i.e. for x = 15 the cipher size is 16
• This results in cleartext lengths smaller than a multiple of 16 being rounded up to the next higher multiple and lengths which are an exact multiple of 16 also being rounded up, which results in getting a complete 16 bytes of padding.
• It is common to store the IV together with the ciphertext which results in an additional 16 bytes.
• AES can use 3 different key sizes: 128, 192 and 256 bits. The algorithm automatically changes the number of iterations based on the key size used. You don't have to specify the key size, you simply enter the key of one of those three sizes and the algorithm will automatically use the correct number of iterations.