Programmers are frequently afflicted with what I call “there must be a better way” (TeMBaW) syndrome. TeMBaW frequently occurs when you successfully accomplish something new to you. However, after that initial sense of accomplishment, some nagging details start rearing their head like that tickling scratchiness in the back of your throat before you get sick. You may go back to the code you wrote, and start getting hints of the code smell you previously ignored. Or, at some later point, you may just realize that some new skill you’ve acquired could offer significant improvement on previously “completed” projects.

My react-native-webview-leaflet package afflicted me with a severe case of TeMBaW. Sure, it did it’s job; it displayed a Leaflet map in a React Native component. It even did some things that the react-native-maps component didn’t do like provide support for CSS animation of markers, and customized markers including SVG and emojis. However, it suffered from what I felt were several problems, most of which existed because a lack of experience during its creation meant that I just didn’t know then what I know now. …

Introduction

This post is a continuation and improvement of the techniques discussed in a previous post. In that article, I described a technique that combined Expo’s ease of development, Webpack’s packaging capability, Gulp’s task automation, and React Native’s WebView component in order to covert an UI oriented JavaScript library into React Native component. An advantage of using this technique is that it avoided any native code; making the component suitable for use with Expo.

While the previous post is not project-specific, I did implement the technique in my react-native-webview-quilljs and react-native-webview-leafletpackages.

Problems

While functional, this technique possessed several shortfalls. First, the JSfiles used by the HTML file that was displayed by the WebView were not included in the package bundle due to a limitation of the Expo bundling process. The bundler did not import anything that was included using a <script src="myscripts.js"></script> tag. This limitation prevented the JS and CSS files relied on by the HTML file from being bundled in the Expo application. …

Introduction

This post is a continuation and improvement of the techniques discussed in a previous post. In that article, I described a technique that combined Expo’s ease of development, Webpack’s packaging capability, Gulp’s task automation, and React Native’s WebView component in order to covert an UI oriented JavaScript library into React Native component. An advantage of using this technique is that it avoided any native code; making the component suitable for use with Expo.

While the previous post is not project specific, I did implement the technique in my react-native-webview-quilljs and react-native-webview-leaflet packages.

Problems

While functional, this technique possessed several shortfalls. First, the JSfiles used by the HTML file that was displayed by the WebView were not included in the package bundle due to a limitation of the Expo bundling process. The bundler did not import anything that was included using a <script src="myscripts.js"></script> tag. This limitation prevented the JS and CSS files relied on by the HTML file from being bundled in the Expo application. …

If you’ve read my previous posts, you’ve probably gathered that I’m working on some sort of side project. Hopefully, I will get to the point that I’m ready to release my creation, but for now I’ve been content to adjust and tweak as needed. For example, I’ve repeatedly gotten to the point where it made logical sense to break out significant pieces of functionality and place them in their own NPM modules.

Doing this provides multiple benefits. It allows other people to use, and help improve, the functionality the package provides. It also provides the benefit of improved reuse in another project (there’s always another project) by just doing an npm install (or yarn add if you prefer). Additionally, it would allow me to “eat the elephant one bite at a time” vice being confronted with my entire project in one go. …

If you’ve read my previous posts, you’ve probably gathered that I’m working on some sort of side-project. Hopefully, I will get to the point that I’m ready to release my creation, but for now I’ve been content to adjust and tweak as needed. For example, I’ve repeatedly gotten to the point where it made logical sense to break out significant pieces of functionality and place them in their own NPM modules.

Doing this provides multiple benefits. It allows other people to use, and help improve the functionality the package provides. It also provides the benefit of improved reuse in another project (there’s always another project) by just doing an npm install (or yarn add if you prefer). Additionally, it would allow me to “eat the elephant one bite at a time” vice being confronted with my entire project in one go. …

May 2018 Update

Now that I have learned more about using React Native and creating friendlier NPM packages, I’ve made some significant updates to the package detailed in this article.

The package is now called react-audio-player-recorder-no-linking. I chose this new name to emphasize that it includes separate Recorder and Player components vice just a single SoundRecorder component, and that the package does not require linking to native code. This lack of linking maintains the package’s safety to use with Expo.

Additionally, all UI (buttons, badges, etc) has been pulled out of the actually Player and Recorder components and are available as imports. The imported UI items can be provided to the Player and Recorder as props. More importantly, the user can provide their own UI items as props. …

A Quill.js Component for React-Native Applications with no Native Code

Introduction

In the process of finding a text editor capable of creating richly styled text for one of my projects, I stumbled upon Quill.js, “… a modern rich text editor built for compatibility and extensibility”. Based on this statement, it seemed perfect for my needs. I also came across react-quill, a React Quill.js component, which wraps vanilla Quill.js for use in React web applications.

Thanks to my past experience developing the react-native-webview-braintree component, I already knew that wrapping React components in a React-Native webview for use in React-Native apps was a viable option for projects that needed to avoid using native code; for example, projects made using Expo.io. …

Background

This is the fourth and final article in a series of posts about integrating Braintree payments into a JavaScript only (no native code) React Native mobile application. The GitHub repository for this project is located here.

Additionally, this project is available as the react-native-webview-braintree npm package for you to use in your own projects.

This article discusses building the final version of the client using React Native, React, JavaScript, and the version 3 of the Braintree JavaScript SDK. Since this technique builds on the previous articles in this series this post is going to be relatively short. …