DEV Community: Andrei Xavier de Oliveira Calazans

Fixing a PhaseScriptExecution Failure on React Native

Andrei Xavier de Oliveira Calazans — Tue, 29 Aug 2023 15:47:48 +0000

When contributing to react-native-share library I ran into an issue while building for iOS via Xcode.

Their example app lacked a build setting that caused the PhaseScriptExecution step to fail.

The Problem

When building from Xcode I got this issue:

Command PhaseScriptExecution failed with a nonzero exit code

Expanding the error you see a ton of logs:

Looking at the bottom you see that it failed to find the root/index.js file of the project.

While their start:ios NPM script call does set the entry path here that won't get picked up by Xcode.

The Fix

Luckily for us that script phase is a build step within Xcode which we can change.

In the Example app's build phases, we can change Bundle React Native code and images's shellscript that executes react-native-xcode.sh and add the ENTRY_FILE environment variable pointing to the right path.

Do one thing at a time - prefering composition over branching logic

Andrei Xavier de Oliveira Calazans — Fri, 03 Jun 2022 12:56:21 +0000

A simple yet powerful yea - do one thing at a time. Over time you will notice we apply that idea to many patterns in coding.

Pattern to use: prefer extracting and composing differences over using boolean flags:

Simple example is a setter function that uses a different key based on a boolean:

async function setData(data, isLoggedIn) {
  // ...ignore
  const storeKey = isLoggedIn ? 'logged_in_key' : 'logged_out_key';
  await setStoreData(storeKey, data);
  return true;
}

It's best instead to extract storeKey as an argument

async function setData(data, storeKey) {
  // ...ignore
  await setStoreData(storeKey, data);
  return true;
}

While the above example is simple in projects we see many make this mistake.

Classes are typically catch-all places of branching logic.

Tip: everytime you see a branching logic question yourself if it won't benefit from composition.

ps: This is a post zero of a series on writing better code, follow me for more

What are some experienced pros or cons of a database you worked with?

Andrei Xavier de Oliveira Calazans — Fri, 26 Feb 2021 13:16:35 +0000

I'm trying to compile a list of experienced pros and cons on different databases like: MySQL, MongoDB, DynamoDB, MariaDB, PostgreSQL, etc.,. Any database.

What is a pro or con of a database you worked with that you can remember? I'm looking for real experiences, thanks = ).

I’d love feedback
https://twitter.com/Andrei_Calazans/status/1365288230069878784

Explicit Versus Implicit - The Cost Of Implicitness in Programming Comprehension

Andrei Xavier de Oliveira Calazans — Mon, 08 Feb 2021 11:58:20 +0000

For better developer experience always prefer an explicit pattern.

There is an overhead with understanding implicit code. It implies that you know a contextual knowledge not written in front of you.

JavaScript Throwable Functions

In JavaScript, we have no way of signaling if a given function will throw or not. This is the implicitness of calling a function.

// will it throw? Idk
someFunction();

An alternative to make the error handling of a throwable function explicit is to request the user to pass an error callback.

type SomeFunction = (onError: (err) => void, onSuccess: (res) => void) => void;

Another alternative is to always return, and in this case you can return the result of a error value. See Maybe wrappers.

type SomeFunction = () => Maybe<Result>;

React's useEffect

React's useEffect is an example of the drawback to implicitness. Regardless to how powerful it is, it is hard to initially understand what it does by just looking at the code. On the contrary the class component lifecycles were very explicit to what it did: componentDidMount for example.

Node JS Express' Error Middleware

The Node JS Express library allows you to handle errors by passing a callback to the app.use that has four arguments: err, req, res, and next.

While this function signature might seem obvious with a statically typed language if the type carries the name of its purpose, with plain JavaScript this is an implicit assumption that someone won't understand by just looking at it.

Express error handling

Define error-handling middleware functions in the same way as other middleware functions, except error-handling functions have four arguments instead of three: (err, req, res, next).

expressjs.com, https://expressjs.com/en/guide/error-handling.html, (Accessed Saturday, February 6, 2021)

Anonymous inlined functions are examples that carry implicitness overhead. The previous example of Express's error handling function signature becomes even harder to understand when you see the app.use(...) with an inlined callback. It is not clear at all what the callback is doing without reading the function block.

// Gotta read function block.
app.use((err, req, res, next) => { ... });

// Explicit understanding.
app.use(handleErrorMiddleware);

Further On Anonymous Functions

The same occurs in other examples. In my experience, JavaScript's Array.reduce is a common example of the implicitness overhead. If it takes a properly named function as a callback it becomes easier to grasp, else it requires more reading.

58% Is Spent On Comprehension

According to this article we spend most of our time in a codebase trying to understand it. If you agree that explicit code is easier to understand than it should influence how we write code.

This paper is quite interesting in that it describes in great details how the figures are obtained. And it says that Comprehension took on average ~58%

blog.feenk.com, https://blog.feenk.com/developers-spend-most-of-their-time-figuri-7aj1ocjhe765vvlln8qqbuhto/, (Accessed Monday, February 1, 2021)

Plus

Please do not confuse explicit versus implicit with declarative versus imperative.

Following a good naming convention and not writing implicit code will take you a long way to having an easier to comprehend codebase. See https://github.com/kettanaito/naming-cheatsheet for naming convetion recommendations.

Despite the above highlighting how well named functions can help make a codebase more explict, using a purely functional programming library on your codebase to help can also add a lot of overhead to the codebase comprehension all because of the same reasons - implied knowledge.

Can we implement a Monorepo structure without Yarn Workspaces or Lerna?

Andrei Xavier de Oliveira Calazans — Wed, 05 Feb 2020 19:56:17 +0000

In order to simplify dependency management, code reuse, and collaboration across teams, many projects have sought out to use the Monorepo structure.

To implement this structure most projects decide either on Yarn Workspaces or Lerna to accomplish this feat. The difference between the two can be simplified to the fact Lerna can do everything Yarn Workspaces can including use it as a base, and provide sophisticated publishing and version management features to even publish projects independently from each other.

The Problem

Yarn Workspaces has proven to be quite burdensome to maintain when working with React Native due to React Native's assumptions. Overall, as your codebase progress and new updates occur, you might need to update and fix the Monorepo structure. To avoid having this kind of issue, and to also enjoy similar benefits. You could instead structure your Monorepo without Workspaces.

How could we structure a Monorepo without `Yarn Workspaces`?

Under the same repository, you could have multiple independent projects linked by installing it via a relative path. Each project or module will have its own package.json file which you can create with yarn init.

- apps
   - app_one
   - app_two
- shared
   - module_one
   - module_two

app_one and app_two can consume the shared module by installing it as follow:

yarn add file:../../shared/module_one

This will add the following to your package.json

"module_one": "file:../../shared/module_one",

Note, To avoid reinstalling the same dependencies make sure to declare modules as peerDependencies inside your shared modules if you also use them.

This approach has the benefit of being compatible with NPM as well.

Possible Problems

If your shared modules have external dependencies and for some reason, you install them by running yarn inside shared/*, you have to always remember to remove the node_modules folder before running your app, else you will have name collisions.

Conclusion

There is a price to be paid by abstractions. This does not mean abstractions are negative, it only means we should look for simplicity to achieve our goals, else we will die maintaining. I hope this post displayed a simple and less abstracted way to handle Monorepo structures.

How to interop between Objective-C and C++?

Andrei Xavier de Oliveira Calazans — Wed, 22 Jan 2020 21:09:46 +0000

In the world of cross-platform, it is common for the need to create bridges of communication between different languages. While working with React Native and iOS, I stumbled on a need to interop with a C++ class. This post covers how you can communicate between Objective-C and C++ code.

Using Objective-C++

You can transform your Objective-C file (.m) to Objective-C++ (.mm). This by default enables you to call any C++ code in your Objective-C++ file.

MyObjective_c_file.mm

#include "SomePrivateCppClass.h"

@implementation MyObjective_c_file
- (instancetype) init
{
  // Add your logic here
  SomePrivateCppClass::someMethod();
}

@end

Note - Sometimes you can have issues with this approach especially when your C++ interface is importing code that causes an issue for the Objective-C compiler. To overcome this you can do the next step

Interopping with a C interface to call an Objective-C function from C++

When file separation is required due to external dependencies. You can interop by using a C interface.

C.interface.h

void callFromCpp(const char *dataPayload);

MyObjective_c_file.mm


@implementation MyObjective_c_file
...
 - (void)myMethod: (NSString *) dataPayload {

  // Your logic here
}

@end


void callFromCpp(const char *dataPayload) {
     NSString *convertedString = [[NSString alloc] initWithCString: dataPayload encoding:NSUTF8StringEncoding];

     MyObjective_c_file myInstance = [[MyObjective_c_file alloc] init];
    [MyObjective_c_file myMethod: convertedString];
}

YourCppClass.cpp

YourCppClass::WhatEverMethod() {
  callFromCpp(stringData.c_str());
}

Passing pointers with a C interface to call a C++ method.

When using a C interface, you can also pass a pointer of your C++ class in order to call it from your Objective-C++ code (This is ideal when you can't include your C++ file due to dependencies).

In this case, you will instantiate your Objective-C class by calling a C function from your C++ method, then pass a pointer of your C++ class to your Objective-C interface for it to consume it.

C.interface.h

void initFromCpp(long castBridgePointer);

MyObjective_c_file.mm

#include "YourCppClass.h"

@implementation MyObjective_c_file
static YourCppClass *pointerToBridge;
...
- (void)storeCastBridgePointer: (long) ptr {
    pointerToBridge = (YourCppClass *) ptr;
}

@end

void initFromCpp(long castBridgePointer)
{
     MyObjective_c_file myInstance = [[MyObjective_c_file alloc] init];
    [myInstance storeCastBridgePointer: castBridgePointer];
}

YourCppClass.cpp

YourCppClass::YourCppClass() {
  // whatever logic...

  initFromCpp((long) this);
}

Conclusion

Interop between C++ and Objective-C is not too complicated. The purpose of this post is to bring both solutions, the plain Objective-C approach and C interface approach, into a single post where anyone can reference in the future

Bridging the emotional barrier of a code rewrite.

Andrei Xavier de Oliveira Calazans — Fri, 23 Aug 2019 19:47:58 +0000

As a developer, we are like artists, we take pride in the code we write. Have you ever spent a significant number of hours, working on a feature, taking careful steps to test it and validate its functionality? If yes, then someone might have also told you to change it, if not completely at least partially. Well, I have been in that situation. Despite a few years of experience, the stress and emotional barrier generated by this change is always enormous.

How to deal with this? It is unquestionable how hard it is to deal with this emotion, the feeling of being disappointed, unmotivated, discordant. We can not deny the fact that we are emotional beings easily tampered with. The first step is to admit your emotions. Think about them, try to identify why you are feeling in such a way. The second step is to vent it out, try to put your feelings in words, tell the story of how you arrived at that feeling. It is often common while venting, for the person to realize what is behind his/her emotional state because he/she is hearing him- herself.

The Someone

Finding the ideal someone to talk to can be hard. It’s a good idea to have a friend, who you can be open about anything, who is not biased or intoxicated by the same feelings as you. You might want to avoid your coworkers for that reason since they share the same context, they might feel the same pain. It won’t help if the person you are venting to is motivating your negative feelings.

Do not ignore your feelings. When a feeling was triggered by an underlying trauma, which we often have no clue about. It will easily go away after venting. When we try to evaluate something rationally and it does not make any sense our brain discards it. However, do not ignore this, if this feeling keeps coming back on similar triggers you should seek for help with professional therapists.

Self-awareness is a great tool to deal with our emotions. Love yourself, take care of yourself. Thank you for reading this, I wrote this article after facing an emotional issue triggered by a code rewrite. It shocked me how intense I felt. After dealing with my emotional state rationally. I tried to think of all of the things which caused me to feel the way I felt. I found out a few interesting things about myself in this process which I believe made me grow emotionally. Hopefully, this text will inspire you to be aware of your emotions and take care of yourself.

Saying no is hard because we are a species that (sadly) treats agreement as affection and denial as rejection. When people disagree with us or turn us down, we routinely (and typically incorrectly) interpret it as evidence of enmity.
https://hbr.org/2019/08/how-to-say-no-at-work-without-making-enemies

Choosing between React Native and Flutter

Andrei Xavier de Oliveira Calazans — Mon, 05 Aug 2019 23:13:41 +0000

Cross post from my own blog post

The rise of Flutter brought doubt to the decisions for a new mobile project. This doubt did not exist back in 2016/17 when someone needed a cross-platform mobile solution. Back in 2016/17, there were fewer options¹, it was obvious that if you wanted a cross-platform solution with JavaScript you would choose React Native since it outperformed its competition.

We are no longer questioning the viability of cross-platform, we are now deciding which solution is best. React Native and Flutter are great options to choose from despite other possible solutions e.g. Xamarin and others.

What should one know before deciding which is the best option for their project's requirement?

Architecture

The first thing one must know is the core differences between React Native and Flutter. React Native, for each platform, renders native widgets, its JSX Components translates to native counterparts. This differs from previous attempts of using JavaScript to write mobile apps because despite using JavaScript to declare UI elements, under the hood React Native is rendering Platform Native UI Widgets.

Flutter in the other hand does not render native widgets. It relies on a rendering engine to paint 2D UI elements. Flutter's engine, written primarily in C++, provides low-level rendering support using Google's Skia graphics library². This architecture decision provides Flutter with low-level control of rendering, enabling it thus for possible performance improvements.

Most UI elements will not display much difference when rendered by a rendering engine or the platform's widgets. The difference is often noticed on elements that interact with Users. The native UI elements usually have unique behaviors on each platform. For example, screen transitions, on iOS the screens slide in, while on Android the slide feels more like a fade-in. Also Text Inputs, these have accessibilities built-in by the platform. The rendering engine has to create all the basic functionalities of the Text Input, copy and paste, the positioning of the cursor, and even displaying the text.

The React Native core team has commented that it was a conscious decision to render native widgets instead of rendering UI elements themselves, according to them, it never seemed like the right approach for the following reasons; They didn't want to reimplement everything provided by the platform; The amount of work required to reimplement everything and keep up with platform updates, including support to multiple OS looks, both new and old³.

While Flutter, on the other hand, it attempts to provide identical UI look and feel on all platforms, Reflectly, an App which was originally written in React Native, was rewritten in Flutter with this in mind⁴. Flutter enabled Reflectly Development team to write an App on iOS and expect the exact same look and feel on Android.

It is unneglectable the effort of writing a cross-platform solution as Flutter requires more resources than React Native. Flutter is trying to match Native UI widget's behavior and although they have released a 1.0 version, this is an ongoing work⁵.

Developer Experience

When does Developer Experience decide the technology to use on a project? Hopefully, always. Good developer experience enables the Development team to write better Software. It keeps Developers happy. React Native made a big impact on mobile development by introducing hot reload and a declarative UI framework⁶. These two points increased developer productivity and overall happiness.

After developing Mobile Apps for almost 3 years using React Native, using Flutter for the first time left me a great impression. It has done an amazing job at creating a great onboarding experience by providing Flutter Docter, Hot reload, and well documented Docs. It is safe to say that anyone with Mobile development experience can be productive with Flutter exceedingly fast.

The React Native developer experience is an ongoing improvement process. Until last year, the attention given to the open-source community and consequently Developer Experience if compared to the efforts given today were smaller. Since the end of last year, React Native's core team has made perceptible efforts in improving how it interacts with the Open Source community. These efforts can be noted by the "What do you dislike about React Native?" versions 1 and 2. Dan Abramov is currently in charge of revamping the hot reload module⁷ which has been subject to some bugs.

Available UI elements

Both Flutter and React Native provide all the UI elements you need, nonetheless, each has taken a different approach at this. Flutter tries to deliver first-class support to all the UI elements you might need, it has a long list of widgets⁷, its goal is essentially for you to not need any third-party integration, it encourages you to write your own Widget.

React Native on the other hand, since it is an App rendering Native UI Widgets, it is striving towards a lean core⁹, where React Native will host the minimum set of modules you need, and leave any other dependencies to be managed by third-party open source. With React Native, there is no overhead on integrating native Views or Modules, just the cost of the communication through the bridge which is the reason for an architecture rewrite codenamed fabric¹⁰.

React Native Lean Core strategy to some sounded like a bad idea, removing some of the UI elements from the main repo meant others outside of Facebook would have to step up to contribute. The Lean Core ended up being a positive surprise, All extracted modules have received maintainers and have been updated more than ever.

It is important to note that if your App requires a native UI View integration, Flutter is responsible for all the rendering, therefore, when you need to render a Native UI View, either Android or iOS, it must embed the view in Flutter's hierarchy. For iOS the Documentation notes that this is an expensive operation¹¹ and I'll add that for Android it should not be super smooth since embedding views is not straight-forward.

Upgrading

Breaking changes are the main problem when updating. React Native's longer life has displayed multiple moments of frustration due to updates. This is not unique to React Native, it is rather a Software Development problem. Despite Flutter's shorter existence, it has already encountered moments where it needed to introduce a breaking change¹³. On a survey by Flutter's Core team, it questioned its users if breaking changes for a greater good was acceptable¹².

There is evidence that both communities are doing it's best to solve the updating issues by providing clear documentation and tools to help. Flutter has provided a Github Wiki¹³ for such occasion. While React Native's Core team and community have created a tool¹⁴ and documentation to deal with this.

Despite Core teams efforts, they are not exempt from the issues caused by targeted platform updates. AndroidX has been the reason for much efforts to correctly adapt to it¹⁵.

Community

For open-source projects, a healthy community can be a strong asset. Although Flutter is quite new, it has gotten a lot of traction and it is growing. Evidence of its growth can be noted in Insights from Flutter's first user survey of 2019¹². React Native's community is quite strong, driven by the whole JavaScript ecosystem. Both receive contributions from external development teams, most notably React Native has received many contributions from Companies like Microsoft, Callstack, and Expo¹⁹. Flutter has many external contributions as well, however, we are not able to clearly identify where they are coming from. In this category, Flutter and React Native have displayed confidence.

Performance

Hundreds of posts have been written about React Native versus Flutter, all of them affirm that Flutter is more performant than React Native, however, they all lack benchmarks. All these posts base themselves off the logic behind
Flutter's architecture. In theory, Flutter is faster. The Dart code (both the SDK’s and yours) are ahead-of-time (AOT) compiled into a native, ARM and x86 libraries^20, thus, it is consumed faster by native code. React Native JavaScript thread must cross a bridge through batched async calls every 5 milliseconds. React Native, in theory, is also trying to solve the bridge issue with Fabric, which would enable JavaScript to communicate faster and synchronously through host records held in C++.

If we wrote two apps, one in React Native and another in Flutter with a couple of screens you will not really notice a difference. Only one post that contained benchmarks was found on the internet¹⁶. It was a timer app, by looking at the benchmarks you can see that it displayed a very small difference between a Native Android, Flutter, and React Native. However, this post has a flaw, it did not evaluate the key points where performance really matters, which are Animation and large lists.

Animation is a key point for performance. User will perceive the lag on a slow device. By default, React Native will loose in this test, it comes with an Animated API that is written and runs on the JavaScript thread. There are many posts about how the Animated API is slow¹⁷. To solve this issue you can use React Native Reanimated which solves this by running everything on the native thread¹⁸.

Even with the possible improvement to animations with React Native, you can't deny the fact that Flutter is using Skia as a rendering engine. This is a very performant framework and in Flutter's release, it displayed the capability of rendering 120 FPS on an Android device.

With lists, Flutter also does an amazing job by providing an out of the box API specifically for large lists. ListView.builder delivers virtualization out of the box with really high performance. On React Native, you can achieve acceptable performance with FlatList, however, it requires some tweaking as you can see on the Optimizing FlatList Configuration post.

React Native Time to interaction on Android Devices has also been subject of questioning. Nonetheless, in an effort to improve this, Facebook employed resources towards writing a JavaScript Engine to improve its performance on Android devices. Hermes is a JavaScript Engine optimized for React Native.

Conclusion

Some other points should also be taken into consideration, like the ecosystem. JavaScript is one of the most popular and used languages. On a recent project at G2i, the decision to go with React Native instead of Native development was mostly because we wanted to share all of the services and data logic already available in JavaScript.

Flutter and React Native are great tools for cross-platform development. Either one will deliver a high-quality Application.

About me

Hi! I'm a Software Developer focused on JavaScript. I love talking about Software Development, you can always reach out if you would like to chat.

Thank you for reading!

References

[1] Most only considered React Native or PhoneGap/Cordova, which were very different from each other, Flutter despite not being a JavaScript solution but with Dart, which is very similar to JavaScript in its C like syntax, was not stable to be considered.
[2] Wikipedia contributors. (2019, June 30). Flutter (software). In Wikipedia, The Free Encyclopedia. Retrieved 14:04, July 7, 2019, from https://en.wikipedia.org/w/index.php?title=Flutter_(software)&oldid=904189137
[3] Reactiflux QA React Core Team. (2019, January 24). In reactiflux.com transcript, retrieved from https://www.reactiflux.com/transcripts/react-native-team/#youitv-engine-one-currently-binds
[4] Reflectly App presentation. (2019, Mar 7). In Mobile World Congress 19, retrieved from https://youtu.be/hdOxvNQbies?t=746
[5] On July 7th, 2019, we can find the following issues in Flutter's repository related to UI elements behavior which would not exist if they were using Native UI Widgets: https://github.com/flutter/flutter/issues/35068, https://github.com/flutter/flutter/issues/35577, https://github.com/flutter/flutter/issues/35694. There are more this is just an example.
[6] We can see the evidence of this impact by the number of declarative mobile frameworks/toolkits which came after React Native. Flutter, SwiftUI, Jetpack Compose
[7] Widget index https://flutter.dev/docs/reference/widgets
[8] Ticket related to the broken hot reloading module https://github.com/facebook/react-native/issues/18899
[9] Ticket related to Lean Core https://github.com/facebook/react-native/issues/23313
[10] This is a good overview of the current bridge architecture, https://hackernoon.com/understanding-react-native-bridge-concept-e9526066ddb8. Issue corresponding the Fabric architecture https://github.com/react-native-community/discussions-and-proposals/issues/4.
[11] Embedding iOS views is an expensive operation and should be avoided when a Flutter equivalent is possible. https://api.flutter.dev/flutter/widgets/UiKitView-class.html
[12] Insights from Flutter's first user survey of 2019. (2019, April 11). In Medium post, retrieved from https://medium.com/flutter/insights-from-flutters-first-user-survey-of-2019-3659b02303a5
[13] Flutter's Handling breaking changes Wiki https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[14] React Native's Upgreade Helper https://github.com/react-native-community/upgrade-helper
[15] Flutter and React Native's evidence of AndroidX support efforts. https://flutter.dev/docs/development/packages-and-plugins/androidx-compatibility
https://github.com/react-native-community/discussions-and-proposals/issues/129
[16] Alex Sulivan - Examining performance differences between Native, Flutter, and React Native mobile development. Thoughtbot dev site: https://thoughtbot.com/blog/examining-performance-differences-between-native-flutter-and-react-native-mobile-development
[17] Various posts complaing of Animated performance: https://www.reddit.com/r/reactnative/comments/6ex9y1/brutally_slow_animations_on_android/, https://stackoverflow.com/questions/48928229/slow-animations-in-reactnatives-android-app
[18] react-native-reanimated https://github.com/kmagiera/react-native-reanimated
[19] React Native Repository Pull Requests from Amazon, Callstack, and Expo
[20] https://flutter.dev/docs/resources/faq#how-does-flutter-run-my-code-on-android

DEV Community: Andrei Xavier de Oliveira Calazans

Fixing a PhaseScriptExecution Failure on React Native

The Problem

The Fix

Do one thing at a time - prefering composition over branching logic

What are some **experienced** pros or cons of a database you worked with?

Explicit Versus Implicit - The Cost Of Implicitness in Programming Comprehension

JavaScript Throwable Functions

React's useEffect

Node JS Express' Error Middleware

Further On Anonymous Functions

58% Is Spent On Comprehension

Plus

Can we implement a Monorepo structure without Yarn Workspaces or Lerna?

The Problem

How could we structure a Monorepo without Yarn Workspaces?

Possible Problems

Conclusion

How to interop between Objective-C and C++?

Using Objective-C++

Interopping with a C interface to call an Objective-C function from C++

Passing pointers with a C interface to call a C++ method.

Conclusion

Bridging the emotional barrier of a code rewrite.

The Someone

Choosing between React Native and Flutter

Architecture

Developer Experience

Available UI elements

Upgrading

Community

Performance

Conclusion

About me

References

What are some experienced pros or cons of a database you worked with?

How could we structure a Monorepo without `Yarn Workspaces`?