DEV Community: Aymen Marouani

React Hooks to Tame the Complexity

Aymen Marouani — Fri, 28 Feb 2020 14:40:57 +0000

Hooks are a new feature introduced by React 16.7.0-alpha that allows the use of state (and other features like context, store or life cycle) outside the scope of a class namely in a pure function. React hooks were first introduced (alongside other features like Suspense, Time Slicing and Profiler) to the public in ReactConf 2018 by Sophie Alpert and Dan Abramov (one of the creators of Redux).

Motivation and Background

React Hooks are meant to solve some problems and limitations that the React Team in Facebook noticed. We can summarize those limitations in three main problems:

"Wrapper Hell": components as classes tend to clutter in a big intricate hierarchy that has to pass properties between them and encapsulate each other. This can be seen in big projects where extra layers of abstraction wrappers serve to pass properties and extract reusable logic. Things become more complicated when forced to update the structure of the hierarchy by moving component with their wrappers.
"Giant Component": when creating a component, we need usually to implement its life cycle methods (componentDidMount, compnentWillUnmount ...) and it's hard to separate them from the class, so this will increase component's size when we have to add more logic to them.
"Hard Classes": a stateless react component written as a function requires more effort to migrate it to a class form. In addition, the React Team noticed that classes are hard to optimize by the compiler.

The above limitations have as source the fact that React doesn't have a smaller unit than the class context to encapsulate statefull behavior. In their way to solve this problem, the React Team opted for the first time to adopt the RFC approach (Request for Comment) and started tackling the root cause (the atomicity of the class) by restraining the solution to the following main criteria:

"opt-in": the solution must be neither mandatory nor intrusive, i.e. it'll not oblige the current code to adopt them and it can be removed without collateral effect.
"retro-compatible": don't break the current code. Hooks can live alongside class components.

Introducing React Hooks

Simply a Hook is a function that fetches React context data for the functional component. In order to enable this feature, we have to import a React version above 16.7.

Let's consider this simple introductory example:

import React, { useState } from 'react'
import ReactDOM from 'react-dom'

function SimpleHook() {
  const [count, setCount] = useState(0);

  return (
    <React.Fragment>
      <div>A Simple Hook</div>
      <div>the count is <span>{count}</span></div>
      <div>
        <button onClick={() => setCount(count + 1)}>Increment</button>
        <button onClick={() => setCount(count - 1)}>Decrement</button>
        <button onClick={() => setCount(0)}>Reset</button>
      </div>
    </React.Fragment>
  );
}

const mountPoint = document.getElementById("app");

ReactDOM.render(<SimpleHook />, mountPoint);

this example creates an increment decrement control on a given integer displayed as a label.

In this example we have a page that uses a single functional component. With Hooks, it has a state accessed by importing the useState function and initialized using the directive

const [count, setCount] = useState(0);

We declared both the state and the set-state by calling useState and passing the initial value 0. Changing the state is done by calling the previously declared state setter

<button onClick={() => setCount(count + 1)}>Increment</button>

useState is the simplest Hook and we have various types, mainly:

useEffect, provided for life cycle behavior implementation (same purpose as componentDidMount, componentWillUnmount)
useContext, to access React context API (sort of a global state container)
userReducer, to manage local state using pure functions called reducers

More details on how to use those Hook types in this URL. Custom Hooks can be also defined as shown in this section from React Hook API reference.

Conclusion

Hooks are the new way for React to define elementary function based components by allowing a statefull behavior outside the old class definition. They'll live with the legacy and promote design flexibility and code reuse.

References

For more details you can consult the following links:

ReactConf 2018 video presentation: https://www.youtube.com/watch?v=dpw9EHDh2bM
The RFC: https://github.com/reactjs/rfcs/pull/68
Official page entry: https://reactjs.org/docs/hooks-intro.html

Java 11, the Good Parts

Aymen Marouani — Tue, 25 Feb 2020 14:45:40 +0000

Announced in 25 September 2018, Java 11 is the latest long term support release by Oracle for the Java community. The following is a listing of the most important features and changes:

Type inference for Lambda parameters

The var key word was introduced in Java 10 to implement local scope variables with dynamic type inference.

var aString = "This is a String";

In Java 11, the var key word can be used to qualify a given lambda parameter

Predicate<String> notNull  = (var u) -> u != null;

HTTP Client

This is known to be an incubating feature from JDK 9. It's a standard API to support HTTP/1, HTTP/2 clients, synchronous, asynchronous and in a reactive-functional style. This being illustrated by the following code from the Oracle HTTP Client Page:

HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
      .uri(URI.create("http://openjdk.java.net/"))
      .build();
client.sendAsync(request, asString())
      .thenApply(HttpResponse::body)
      .thenAccept(System.out::println)
      .join();

TLS 1.3

Java 11 comes with the implementation of the Transport Layer Security Protocol (TLS) version 1.3. TLS is protocol for providing secured data exchange between two ends of a communication channel. It defines a secure communication channel as having those 3 main criteria:

Authentication
Confidentiality
Integrity

TLS 1.3 consists of two main specifications:

Communication establishment, aka Handshake phase management, where the two peers negotiates the security of the exchange via key exchange and cryptographic algorithms
Data Exchange phase, aka Record Protocol where the traffic is considered as a transit of records protected by the parameters from the first phase.

Enough as a digression, please see the link in the References paragraph for more. The JDK steering committee included the TLS 1.3 implementation because of its robustness as a security protocol and to keep competitive with other vendors implementing it. Following suit, the TLS implementation includes various cryptographic algorithms for signature and encryption.

Performance related features

JDK 11 put a big deal on performance enhancement and tooling. Aware of the fact that Garbage Collection is the pivotal point for Java performance, the following features were introduced for GC:

ZGC: although experimental, the ZGC promises low latency time (less than 10ms) and wide range of memory size support (from hundred of megabytes to terabytes). It's only available for Linux x64.
Epsilon GC: a generous GC that allocates memory without reclaiming it. Useful for performance testing and short living Java processes.

Performance tools have a lion share in this release:

Low Overhead Heap Profiling: offers a non intrusive way to monitor Java memory heap allocation. It's in fact a programmatic native API available for the JVMTI (JVM Tooling Interface) to get information about object on the Heap.
Java Flight Recorder: an important tool for low overhead performance data troubleshooting and collection. It produces dump data that can be red by Java Mission Control tool. In a nutshell, we start the tool on the command line as the following

jcmd <pid> JFR.start

where pid is the process id of an already running java application. To specify the dump process file that will record the application's performance status use the command

jcmd <pid> JFR.dump filename=recording.jfr

To stop the recording, issue the command

jcmd <pid> JFR.stop

and the produced file can be imported by other profiling tools.

Deprecation and removal of some features from the JDK

JavaFx is no more a part of the JDK, it's a separate download. Oracle stopped providing 32bit binaries and auto updates via Server JRE.
The following modules are removed:

Corba
JAXB, JAX-WS, JAF and Common Annotations
Nashorn JavaScript Engine is being deprecated
The packing suit of Java WebStart and Java Plugin

For Corba and the other J2EE modules (like JAXB and JAX-WS) the removal was justified by the fact that they can evolve and be maintained outside the JDK sphere and it becomes more and more difficult to sync the changes.

Minor Features

With JDK 11 comes the support for Unicode 10 which means we can print emojies. Another feature is the possibility to execute single java file programs in one pass by calling

java OneClassFileProgram.java

instead of the usual sequence (javac then java). Under the hood, no class file on the disc, all in memory.

References

Main feature page: http://openjdk.java.net/projects/jdk/11
Oracle migration guide: https://docs.oracle.com/en/java/javase/11/migrate/index.html
Oracle HTTP Client: http://openjdk.java.net/groups/net/httpclient/recipes-incubating.html
TLS 1.3: https://tools.ietf.org/html/rfc8446

Project Loom: Java on Fiber

Aymen Marouani — Tue, 25 Feb 2020 14:06:41 +0000

With Java 9 came a whole bunch of ambitious projects to modernize the Java language and enhance the JVM performance; one of these projects is the Project Loom which tackled the multithreading model offered by the JDK. According to the project's page:

The goal of this Project is to explore and incubate Java VM features and APIs built on top of them for the implementation of lightweight user-mode threads (fibers), delimited continuations (of some form), and related features, such as explicit tail-call.

This statement seems not clear for anyone who used the page as the only source to be introduced to the subject of this still incubated and promising feature, but the project was announced in notorious tech conferences mainly Devoxx Belgium in 2018 and before that in an Oracle Java event in 2017. The purpose of this article is to clarify the underlying and the future enhancements expected from this important, yet under development, project. Please note that the code excerpts are taken as it from the project page and are not in a final state.

Motivation Behind

For any serious production ready Java code, concurrency comes as a prominent feature. Failing to fulfill concurrency and parallelism dooms the usability of the final product although its functional facet may be near perfection. In other words, real life Java applications must deal with multi-users, multi-resources, concurrent access and sporadic calls. For that reason, Java offers a threading model conform to the low level basic concurrency patterns and principles (locks, concurrent data structures, join-yield calls, etc...). Given this, implementing asynchronous and concurrent proof code presents the challenge of being an art apart and a burden for maintenance. A top of this, we have to use external libraries to manage Thread Pools in Java. So here comes the need to make the threading API in Java more accessible to the users via a user mode threads (called fibers) unlike the low level standard threads.

fiber = continuation + scheduler

The main idea is to use simply manageable user level threads called Fibers. Fibers are user mode thread which means that they are created and managed by the JVM unlike the normal Threads spawn by the OS via the JVM system calls. But before explaining more the concept of fibers, let's understand the concept of Continuation. After all, the Project Loom is introducing three concepts:

Fibers
Continuation
Tail-calls

Forget, for the moment, about the last concept (tail-calls) as it's not yet developed. To those days, the first two concepts are almost ready.
Fibers are based on the concept of continuation; a Continuation is a demarcation of a flow of execution to allow the play-pause actions. In other words, a continuation allows us to design a piece of code to be started, paused, and then restarted again from its previously stopped point. The prototype for this class is

class _Continuation {
    public _Continuation(_Scope scope, Runnable target) 
    public boolean run()
    public static _Continuation suspend(_Scope scope, Consumer<_Continuation> ccc)

    public ? getStackTrace()
}

So how continuation is related to the fibers? In fact, fibers are meant to be attached to one thread according to this logic:

A flow of execution, meant to be concurrent and parallalised, is wrapped by a continuation.
When starting the concurrency process, the JVM instantiates as many copies of this demarked continuation as needed.
One thread is then spawn and it will carry the execution of one continuation instance.
When preempted (by a blocking call or by an interruption), the call stack of this continuation is removed from the thread's stack and saved apart to mark the paused execution, this is called parking, and the thread can execute another code.
When needed, the execution resumes by pushing again the saved continuation call stack (un-parking) onto the threads stack and continue from there.

From the above we can see that a thread can hold the execution of multiple fibers and, according to the authors, the already existing scheduler of type ForkJoinPool is suitable for this schema of execution.

class _Fiber {
    private final _Continuation cont;
    private final Executor scheduler;
    private volatile State state;
    private final Runnable task;

    private enum State { NEW, LEASED, RUNNABLE, PAUSED, DONE; }

    public _Fiber(Runnable target, Executor scheduler) {
        this.scheduler = scheduler;
        this.cont = new _Continuation(_FIBER_SCOPE, target);

        this.state = State.NEW;
        this.task = () -> {
              while (!cont.run()) {
                  if (park0())
                     return; // parking; otherwise, had lease -- continue
              }
              state = State.DONE;
        };
    }

    public void start() {
        if (!casState(State.NEW, State.RUNNABLE))
            throw new IllegalStateException();
        scheduler.execute(task);
    }

    public static void park() {
        _Continuation.suspend(_FIBER_SCOPE, null);
    }

    private boolean park0() {
        State st, nst;
        do {
            st = state;
            switch (st) {
              case LEASED:   nst = State.RUNNABLE; break;
              case RUNNABLE: nst = State.PAUSED;   break;
              default:       throw new IllegalStateException();
            }
        } while (!casState(st, nst));
        return nst == State.PAUSED;
    }

    public void unpark() {
        State st, nst;
        do {
            State st = state;
            switch (st) {
              case LEASED: 
              case RUNNABLE: nst = State.LEASED;   break;
              case PAUSED:   nst = State.RUNNABLE; break;
              default:       throw new IllegalStateException();
            }
        } while (!casState(st, nst));
        if (nst == State.RUNNABLE)
            scheduler.execute(task);
    }

    private boolean casState(State oldState, State newState) { ... }  
}

Advantages and Limitations

Advantages of this approach are mainly less memory overhead (some 100Kb against 1Mb for threads), reduced context switching time between tasks and a simple threading model.
The main limitations reside in the management of thread stacks containing native methods calls and the impact on the existing concurrent APIs.

References

The project main page: https://openjdk.java.net/projects/loom
The Proposal: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
Belgium 2018 Devoxx Talk: https://www.youtube.com/watch?v=vbGbXUjlRyQ
Oracle Talk: https://www.youtube.com/watch?v=J31o0ZMQEnI

WebAssembly, a Web without JavaScript

Aymen Marouani — Tue, 25 Feb 2020 10:02:18 +0000

According to the official site:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high- level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

In a nutshell, it's a technology that allows code written in other languages; mainly C/C++ and Rust; to be executed by a VM embedded in the browser as a low level byte code.

History

The idea behind Wasm is not new, some precursors existed like Google Native Client and asm.js, we perhaps remember the Java Applets. Wasm started as a project by Mozilla and was announced in June 2015. The first PoC was in March 2016 and consisted on a Unity game running on FireFox. By 2017, the majority of the browsers including Chrome, Safari and Edge implemented the Wasm VM. In February 2018, Wasm was adopted as W3C standard as the Javascript core specification and Api have been published by a group of engineers from Mozilla, Microsoft, Google and Apple.

Design and Main Ideas

The de facto language for the Web is JavaScript, a high level interpreted programming language executed by various engines like V8 in Chrome, SpiderMonkey in FireFox and Chakra in IE. Besides that, JavaScript is weakly typed and dynamic. The previous facts imply that JavaScript is not an ideal language for performance for the following reasons:

The process of interpretation leads to the time consuming process of parsing and processing the code before executing it.
Byte code generation for the engine is usually optimized by a technique called JIT (Just in Time) compilation where parts of code are analyzed (profiled precisely) to spot frequently used parts to be precompiled as a "compilation cache". Although the apparent performance gains, profiling can add overhead to the code execution life cycle.
Being weakly typed and dynamic leads to an additional effort of inferring variable types and scopes which add more processing time.
Finally, GC and mono-threading will make things all but faster.

Being not well suited for performance is not a major issue for the JavaScript programming language as the majority of Web related coding is frequently limited to DOM manipulation, regular expression parsing or GUI component instantiation and lifecycle management. But when it comes to some more intensive tasks like running a 3D game or a Virtual Reality scene, media streaming or even high performance large DOM manipulation; certainly JavaScript will not be the first choice. Those performance demanding tasks are already coded in the low level language C/C++ and are well proven, so the idea was to be able to integrate the already coded high performance C/C++ libraries (like OpenGL for 3D rendering) on the Web page. In other words, porting a high-performance code to the browser.
WebAssembly made this possible by adopting a compiled byte code from an already existing C/C++ or Rust code. This already compiled byte code will be executed by a stack based virtual machine supported by the browser. Wasm Specification consists of those two main parts:

A byte code specification for the stack base VM to implement.
A JavaScript API to allow any Wasm code to call or access its surrounding environment (DOM, passing arguments).

Tools and Usage

WebAssembly tooling is based on EmScripten, the main goal of those tools is to take a C/C++ source code and generate a Wasm module in addition to a JavaScript "glue" to make the module readable by the browser.

A typical flow for C/C++ source code (factorial in this example) will involve the following:

Generating a Wasm module by calling:

emcc factorial.c -s WASM=1 -o factorial.html

Running the resulting Wasm module and JavaScript glue code:

emrun --no_browser --port 8080

Future Road Map

Although accepted as W3C standard, the committee has planned the following features:

Threading and concurrency, provide a p-thread like environment execution, shared memory and mutexes.
Garbage collection, allocate and manipulate GC objects from Wasm code.
Exception handling, full implementation of C++ style exception handling.
Bulk memory operations, copying and clearing large chunks of memory with an efficient architecture independent way.

Conclusion

WebAssembly is a technology meant to integrate high-performance portable C/C++ code (or even other languages like Rust) into the JavaScript Web context in order to extend its capabilities to run highly demanding features like 3D or image and video processing.

References

For more details you can consult the following links:

Official page: https://webassembly.org
W3C entry: https://www.w3.org/community/webassembly