Forem: Danilo Woznica

Using Sandpack for React Libraries Documentation

Danilo Woznica — Wed, 19 Apr 2023 16:00:12 +0000

Sandpack is an open-source component toolkit that allows for interactive, live-running code editing experiences in the browser. This in-browser bundler is the engine behind CodeSandbox.

Recently, Sandpack expanded its capabilities by adding support for Node.js templates. With this new feature, users can run Next.js 13, Vite 3, and other frameworks directly in the browser on Chrome, Firefox, and Safari.

With Sandpack's live coding experience, users can get a full live-coding journey from a live sandbox to a close-to-localhost experience:

Sandpack editor: a themeable and responsive full editor experience with syntax highlighting, touch-device support, file explorer, and debug tools.
Real-time edit: an advanced preview that uses NPM dependency support, hot module reloading, caching, etc.
Full development experience: open sandboxes directly in CodeSandbox with one click, which provides a full in-cloud development experience.

By developers, for developers

At CodeSandbox, one of our core values is accessibility: making sure that nothing prevents developers from making their ideas come to life. This is what Sandpack is all about. It greatly reduces the entry barriers for beginner developers who are just getting started with a new library or are unfamiliar with the tools required for local development.

By using Sandpack to run coding examples in your Docs, you allow your end-users to interact with live code directly from the Docs and see the results in real-time without having to leave the page.

Additionally, by providing interactive tutorials and a safe environment to experiment, Sandpack can help developers gain more confidence and build skills more quickly and effectively.

Getting excited? Let's get started with it.

Installing

Install the Sandpack dependency on your project.

npm i @codesandbox/sandpack-react

All the components and the bundler are packed inside the Sandpack component, which is a named export of the package. Besides that, the package contains multiple components, utilities, and typings.

import { Sandpack } from "@codesandbox/sandpack-react";

export default function App() {
  return <Sandpack template="node" />
}

That's it! Now you have an editor and preview component running a basic Node.js server inside of your browser.

Who's using Sandpack?

We've been working closely with the React community to solve real problems. From educational websites to open-source project documentation, we spend a lot on research, design, and testing to remove the friction of coding in a browser and empower content creators.

That's why we believe Sandpack is quickly becoming a go-to tool for anyone looking to provide their users with a seamless, accessible and powerful web development experience.

Let's explore a few projects using Sandpack in different ways.

React documentation: the extra mile implementation

The React documentation implemented a very custom version of Sandpack, which basically relies on the SandpackProvider component to handle the file states, SandpackCodeEditor to edit the code, and SandpackPreview to render the code output.

Everything else—such as the theme, component composition and styles—is built internally, which makes it the most advanced implementation example in the Sandpack ecosystem, and gives an example of how extensible Sandpack can be.

👉 react.dev

Chakra UI: the nicest library playground

With Sandpack components, you can basically build your own CodeSandbox.

Chakra UI understood this, and they implemented other capabilities on top of Sandpack, such as code formatting and shareable URLs. Besides that, you can simply use different code editors, like Monaco, which can provide autocompletion by default.

👉 play.chakra-ui.com

React Spring: documentation can be fun

Sandpack can be the best friend of visual React projects, such as animation APIs and UI libraries.

You can turn static snippets of codes on live examples, reducing the barriers to visualizing the library output, or simply trying out different parameters. This is precisely what React Spring did on their Docs.

👉 www.react-spring.dev

Jest-extended: going beyond the preview component

So far, we have only talked about the default layout (Editor + Preview).

However, Sandpack fits many additional use cases, such as showing the output of unit tests and console logs. That's possible because Sandpack can execute a range of environments, including Jest, as seen on the jest-extended Docs.

👉 jest-extended.jestcommunity.dev

Explore all the features

The examples we shared above are great to see what Sandpack is capable of—but there’s a lot more to unpack!

See below a brief overview of some of the awesome things Sandpack enables you to do.

Templates

Currently, Sandpack supports several templates, from client to server templates:

Static
Angular
React
React TS
Node
Nextjs
Vite
Astro

And many more.

Extensible components

File-explorer: a minimal but very powerful experience to navigate through files. You can open and close folders, and open new files;
Tests: renders a thin wrapper around Jest to run tests directly in the browser;
Console: devtool that allows printing the console logs from a Sandpack client;

More details and examples on Sandpack documentation.

Local packages

Although Sandpack mostly relies on NPM to fetch dependencies, you can also provide local package/dependencies by injecting them into the Sandpack context and test on development libraries.

More information on how to consume local dependencies/package on Sandpack

Themes

The overall style can be set through the theme prop, but Sandpack also offers a set of predefined options through @codesandbox/sandpack-themes, an open-source package that contains many other themes compatible with Sandpack.

Make your project more accessible

Seeing all the love and support that Sandpack gets from the community keeps pushing us forward to make it even better and more powerful.

If you have any suggestions on how we can improve Sandpack, feel free to open an issue on GitHub. And if you have added Sandpack to our docs, we’d love to see the result—tweet it @CodeSandbox.

Sandpack v1: a fresh design and a new accessible API

Danilo Woznica — Thu, 16 Jun 2022 17:10:11 +0000

Since we announced Sandpack, we didn't stop a minute. We've been working hard alongside the community to improve it and make it even better. And to be honest, we're amazed how the community embraced Sandpack. As a result, many projects can now empower their users and provide a better code experience in their own project and website.

But today, we'd like to introduce a new step in the Sandpack journey. We listened to you, and we're very excited to introduce a major release of Sandpack, which takes into account many feature requests, a complete redesign, and a ton of improvements in the API.

What is Sandpack?

Sandpack is a component toolkit that makes it possible to have interactive, live-running code editing experiences in the browser. It is the in-browser bundler that powers CodeSandbox that is now open source.

With Sandpack's live coding environment, you get:

A full editor experience with syntax highlighting.
An advanced preview that takes advantage of npm dependency support, hot module reloading, etc.
One click away from opening your code snippets directly in CodeSandbox.

One step back

The very first version of Sandpack was released in 2018. Since then, we haven't had the chance to take a step back and rethink how you interact with it and how the Sandpack components fit in your website. Plus, we realized that we need to be prepared for the future challenge that might come. That's why we recreated the surface API and the design of the components to open more opportunities for us, and you!

So, at the first look, all the breaking changes introduced in this major version might not look significant. But, they're crucial to keep us evolving the product and still keep it extensible, customizable, and easy to use.

What's new?

A new design, from scratch

We challenge ourselves to come up with a solution that could fit in different layouts and contexts, but still be accessible and customizable. As a result, we created a new set of themes, icons, design tokens, and components from scratch.

Bring your favorite theme to Sandpack

All themes are available now on @codesandbox/sandpack-themes, so which means that you’re able now to contribute to Sandpack and create your favorite theme.

https://sandpack.codesandbox.io/theme

Sandpack file explorer

We listened to you, and now Sandpack has a new component to navigate, open and close files, empowering your sandboxes and examples.

And much more:

SSR: syntax-highlight on the server, dedupe styles, and a more lightweight output;
New API: it fixes many inconsistencies, and improves the discoverability of some options;
Improve error message descriptions;
Support React 18;

Check out the Migration guide and get more info: https://sandpack.codesandbox.io/docs/releases/v1

What's next?

Your opinion is very important to us. As we already said, most of these improvements came from community requests and bug reports. So, if you have any feature requests or want to understand how Sandpack might fit in your project, don't hesitate to reach out on our Discord channel or GitHub repository.

A React code editor

Danilo Woznica — Wed, 19 May 2021 18:34:37 +0000

Have we already exhausted the possibilities of how we interact with our favorite code editor? Have we got so used to how we code to achieve a certain goal we can no longer see any way to involve it?

Since I started to work at CodeSandbox, I've seen myself facing those issues more often. Besides that, I began to wonder how beginners are struggling to rule the code editor and learn their favorite framework simultaneously.

Therefore, I challenged myself to come up with a code editor/IDE for beginner developers focused on ReactJS and what this concept might look like.

The anatomy of a component

The first concept came to me some time ago, when I was teaching a friend of mine more about React and how a component works. I remember I said the component itself has a proper "anatomy". Later, I realized it makes a lot of sense because we know where things are supposed to be in a component.

In other words:

So basically, we can predict what actions the user might take and teach them the best practices. So, this idea evolved to a new concept which are menus with context-sensitive intentions linked to those sectors.

The whole point of this concept is that we can understand the code to provide a way to make a new code editor with whatever framework or even language we want. I just used React to illustrate the idea.

Four lessons I learned from maintaining a 10k stars project on Github

Danilo Woznica — Mon, 30 Nov 2020 13:35:20 +0000

In 2017 I started a new project with a single goal: learn unit testing. Since then a lot of things have happened with react-content-loader (a React skeleton package) and it reached a status that I could never have imagined. It has had countless contributions, suggestions and discussions, and I’ve had the opportunity to interact with many awesome developers around the world.

Also, the open-source community - especially the React one - has taught me a couple of lessons that I'd like to share with present or future project maintainers.

The open-source potential

As the source code is available to any person in the world to check out, different perspectives and opinions come up, and that's amazing. I have no idea how many times the codebase itself and the build script were rewritten from scratch in order to improve legibility, performance and/or compatibility. Also, contributions are not only about coding, but issues with documentation, bug reporting, doubts, and examples.These issues are also very important to build a successful project.

In one of these issues, I realized that sometimes a product needs support to make it more usable. So, I figured out a way to create another new tool which would help the main project; as a result, I came up with create-content-loader to introduce presets, add examples from the community, include documentation and third-party tutorials. From that moment on, the main project improved significantly and became much easier to use. Consequently, more developers can use the project and also contribute to it, creating a sub-community around it.

Focus on one problem and solve it

While the product is growing, it's easy to lose sight of the original goal, which makes us add more and more features in the main project. Edge cases, bugs, alternatives, among others, might come up during the development process, so it's essential to keep the scope defined (but not closed) to keep the purpose of the project clear.

Also, you should try to design APIs as generically as you can. You should try to solve the biggest part of the problem, not all specific cases - that's why it's also important to say no. Sometimes, a small problem may be solved with a workaround instead of being solved by publishing more extra code for everybody else.

Keep yourself up-to-date

Once I solved the main problem in my project, I was able to try so many things such as different builders, testing libraries, framework support and automatization of a few processes. Indeed, my open-source projects are my lab, where I'm able to implement, test and publish improvements which can be tested by many users and websites. Even when some of these changes introduce new bugs or break the whole project, I know that it's part of the learning process, and the community is there helping with solutions.

Be welcoming, be kind, be responsible

Regardless if you're a maintainer or a regular contributor of open-source projects, you've probably faced some situations where you don't know how "open" that project really is. There are a lot of concerns, such as pull requests that are still waiting to be merged, missing documentation or contributing guide, or even a maintainer who doesn't accept any suggestion.

A truly open-source project has its guides, and it welcomes suggestions and changes. Personally, I feel like such behavior and approach in leading a project have made me much better as a developer, thanks to many discussions and change requests. As a consequence, at some point, I realized that the project no longer belonged to me, but to the entire community as well.

Also, you need to be responsible. Every proposal, every push to the main branch and every new contributor added need to be done with certainty that no malicious script or bug is being introduced in the project.

The rewarding part

The benefits of having such a project on a Github profile are undeniable. Besides, a successful open-source project is the opportunity to show your hard and soft skills, since managing a project is not only pushing code to branches, but also organizing, prioritizing, describing, and planning features and bugs.

Success isn't measured in Github stars but rather in complete user satisfaction. To be honest, I still don't know if I've reached that, but I have no doubt that I’ve learned many lessons so far.

Beginner Guide: where to start testing in JavaScript

Danilo Woznica — Sun, 01 Nov 2020 16:58:32 +0000

^{Cover image by Fred Jesus}

One of the most common questions I've been asked by my colleagues recently - when they start writing unit tests - is: well, what should I test? Regardless of the language, one of the main challenges is knowing what to check and how to be sure that it covers all possible bugs - which is almost an impossible task. In the following, I would like to introduce you to one possible way to write tests, making you feel more confident and productive while writing unit tests in Javascript.

It's worth mentioning that the goal here is not to discuss how much unit testing will make your application bug-free nor what kind of technology/library you should use; this conversation is for another time. However, I'm assuming you do want to write unit tests in JavaScript, and you're looking for a guide for writing useful tests.

The nature of the unit test

First of all, you'll need to set up your stack to support unit tests. From vanilla Javascript to React, many excellent tools can provide APIs to make it easier, so I'm going to leave some useful links that will help you in this step, like Jest and React testing library.

Afterwards, there is some consensus in the community on how the unit test should look and its anatomy:

Atomic: each assertion must have a clear purpose and test only one (with expectations) result or piece of the function;
Independent: it needs to be dependency-free, or in cases where that's not possible, it must be mocked. The dependency here means everything in this particular assertion needs to work correctly, like a submit form that dispatches a request. In this case, the request doesn't belong to the submit test;
Pure: the assertion must not have any side-effects that are not handled by the return of the function; for instance: given specific parameters, the returned values should be predictable;
Business logic-only: write assertions that ensure the methods, rules, and the primary purpose of the function is working as expected, and does not causes side-effects, reactions in other modules, or even UI changes.

The three steps

The best way I've found to describe this idea shortly is to split it into three steps, which will guide you when writing unit tests:

Purpose

It might sound obvious, but the most important thing about writing unit tests is to ensure that the implementation is working as expected, along with preventing regressions as development continues. In other words, the test will let you know if some future change breaks the functionality of your tested functions.

So to achieve this goal, ask yourself what the purpose of the function is:

What is this supposed to do? And what is not supposed to do?
Given “these“ arguments, what is the return?
Are the values returned predictable enough?
On a date implementation: performing the test in a different timezone, what is the result? Does it still work?
On the React component: what does it render? Are the events are fired?
Also, in React components: does it support internationalization, click events, state updates, or any kind of dynamic variation that would be worth being tested?

describe('pxToRem - Purpose', () => {
  it('should receive a number and return the value in rem', () => {
    const result = pxToRem(16)

    expect(result).toBe('1rem')
  })

  it('should round the number to keep only one decimals', () => {
    const result = pxToRem(22)

    expect(result).toBe('1.3rem')
  })

  it('should try to convert a string in a number', () => {
    const result = pxToRem('16')

    expect(result).toBe('1rem')
  })

  it('should convert a number to rem with the body font-size argument', () => {
    const input = 16
    const bodyFontSize = 20

    const result = pxToRem(input, bodyFontSize)

    expect(result).toBe('0.8em')
  })
})

Here will be where you could spend more time writing assertions since it needs to cover all internal conditionals, branches, and variations of your implementations. It will make you more confident that your application works.

Avoiding errors

Once you are sure that everything is working correctly, and returning the expected results, the next goal is to try to break your function as hard as possible. Focus on covering all unhandled errors, and create real-world scenarios.

For instance, sometimes you don't have control over arguments and contexts, so it’s good to know how your implementation will behave:

Pass wrong arguments (like undefined, null, or an invalid date) or do not pass some of them (even those that are required);
Execute in different contexts, or perform the function more times than expected;
Regardless of type-checking (like Typescript or Flow), try to mix up all arguments (in some cases, we don’t control the data flow);
Test as close to the real scenario as possible; any way to throw an error here is valid.

describe('pxToRem - Avoiding error', () => {
  it('should return 1rem if the argument is null', () => {
    const result = pxToRem(null)

    expect(result).toBe('1rem')
  })

  it('should return 1rem if the argument is not a number', () => {
    const result = pxToRem(NaN)

    expect(result).toBe('1rem')
  })

  it('should work correctly with the 2nd argument is invalid', () => {
    const result = pxToRem(16, null)

    expect(result).toBe('1rem')
  })
})

Of course, after finding all those errors and places that weren't covered, it’s time to fix it!

Improvements - maintenance

Sometimes writing unit tests might lead to other tasks. Indeed you’ll be able to realize while you’re writing tests that your implementation could be improved or even split in smaller pieces, but keep in mind these changes and improvements enhance the maintenance and that all parts of code are touched by assertions. Think about these issues:

Isn’t there any way to make it simple to maintain?
Could it be split into smaller pieces?
Is every part of the code tested?
Is there a way to turn it faster?
I once read that if it is worth testing, it is worth documenting too. I’d strongly suggest trying to describe how and mostly why you’ve built it like that. Would your future self understand this implementation?

Next steps

I like to think of unit testing not only as writing assertions with your favorite framework but rather as a whole pack. You need to have the right mindset and be willing to refactor many files in order to achieve your goal. On the other hand, you need a starting point, and I guess this provides you a good direction, to then go further with more complex tests and find out your favorite way to write assertions.

Once you’re comfortable with all the content introduced here, I’d recommend looking at some methodologies like TDD and BDD; plus some different approaches to testing applications like end-to-end and integration tests.

Originally published at danilowoz.com

Generating TypeScript types and React Hooks based on a GraphQL endpoint

Danilo Woznica — Mon, 07 Sep 2020 12:42:26 +0000

^{Cover image by Fred Jesus}

Nowadays, developing ReactJS with TypeScript gives us a solid way to write applications: it adds the advantage of type-safety, component auto-documentation, error handling, and accurate autocomplete in the editor code. However, it still requires a considerable effort to write types and keep them maintainable. Moreover, when the data provider is a GraphQL server, it makes you feel like you're doing a useless job, given the server already has its own schemas for types. Seem redundant, right?

With this in mind, GraphQL Code Generator gives us the ability to generate TypesScript typing out of GraphQL schemas. Beyond that, it gives us a couple of plugins to create custom React hooks that don't require any kind of maintenance or workaround to fit into your application.

Among many others, some of the benefits of using this tool:

Codeless: forget about creating the interfaces/types for every GraphQL endpoints; save time and spend effort on what matters;
Development experience: as a result of having the types always available, your editor will provide meaningful autocomplete and error checking;
Types always up-to-date: if your GraphQL endpoint schemas change, your application will be updated and typescript will help you make sure you make the necessary changes.

Setup

First of all, let's install the dependencies needed:

npm i @apollo/react-hooks graphql

npm i @graphql-codegen/cli @graphql-codegen/import-types-preset @graphql-codegen/typescript @graphql-codegen/typescript-operations @graphql-codegen/typescript-react-apollo --save-dev

I'm considering the following folder structure, but of course, feel free to adapt it to your liking, just have in mind that it needs a place to store the schemas that will be fetched by the Code Generator:

📦 my-project
┣ 📂 src
┃ ┣ 📂 pages
┃ ┃ ┗ index.tsx
┃ ┣ 📂 queries
┃ ┃ ┣ 📂 autogenerate
┃ ┃ ┗ my-query.gql
┃ ┗ apollo-client.ts
┣ codegen.yml
┗ package.json

Then, basically, you'll need to create a configuration file at the root of the project, named codegen.yml. The following snippet shows how I usually set it up in my projects, where it generates different files for its own purpose, in other words, split by concerns like GraphQL operations and server schemas:

# Endpoint API, the following URL is a example
schema: https://countries-274616.ew.r.appspot.com/graphql/
overwrite: true
# Format files
hooks:
  afterAllFileWrite:
    - prettier --write
generates:
  # Get schemas from server
  src/queries/autogenerate/schemas.tsx:
    documents: 'src/queries/**/**.gql'
    plugins:
      - typescript
  # Create operations based on queries
  src/queries/autogenerate/operations.tsx:
    documents: 'src/queries/**/**.gql'
    preset: import-types
    presetConfig:
      typesPath: ./schemas
    plugins:
      - typescript-operations
  # 1. Export GraphQL documents
  # 2. React interface
  src/queries/autogenerate/hooks.tsx:
    documents: 'src/queries/**/**.gql'
    preset: import-types
    presetConfig:
      typesPath: ./operations
    plugins:
      - typescript-react-apollo
    config:
      # Optionals
      withHOC: false
      withComponent: false
      withHooks: true

Also, let's add the scripts to generate the schemas and watch the files change in package.json:

"scripts": {
  ...
  "schemas": "graphql-codegen --config codegen.yml",
  "schemas:watch": "npm run schemas -- --watch",
},

And as it turns out in the editor code:

This is only one of the possible ways to use it, as it has many plugins, presets, integrations, and configurations, for different purposes such as to generate React higher-order component, Gatsby integration, prettier and lint the files, among other cool things. Feel free to check out the documentation here.

I've made a repository available with the code above, and you can check it out here.

Originally published at danilowoz.com

The main challenges you're likely to face when creating a crypto wallet on React Native

Danilo Woznica — Mon, 23 Mar 2020 23:13:39 +0000

^{Cover image by Fred Jesus}

Crypto wallets and Decentralised Applications (dApp's) are becoming more popular each day. It is already possible to find a lot of industries adopting a decentralized approach: financial business, social networks, insurance, supply chain, only to mention a few.

Also, the benefits of introducing blockchain technology on mobile devices, for example, are evident enough, and apparently worth the effort for companies which are willing to invest in their development. Factors like immutability, transparency, and security are concepts that, not only users but also business owners, recognise as a must when pondering about digital products.

There is a lot of fuss around React Native versus native apps – and even though that's an entirely different issue – in our understanding, when budget is somehow the matter of interest, React Native is arguably the go-to choice. However, when it comes to implementing blockchain technologies with React Native, the uncertainties are unquestionable: it's a fairly recent environment which still somehow lacks expert developers out there.

Background

We set ourselves to challenge precisely that.

When we were presented with Vertbase, a project which entailed the concerns we just mentioned above, our thoughts were with React Native. Straight off the bat.

However, it was far from being a walk in the park. Even though we've undergone a lot of development in ReactJS, React Native was at the time somewhat new to us and topping it up with blockchain technology, could have been a shot in the leg.

But fear not!

A few hours later and it was perceptible just how efficiently React Native bridged the gap between JavaScript and the Native Modules of both iOS and Android Operating Systems.

With this, and being given the challenge of building a non-custodial wallet that is meant to support a few Crypto assets, asset transactions, and create new wallets – amongst other features – it ended up being a pretty solid App.

However, it was far from a relaxing project. The initial time estimate felt – truly – short due to all the investigation we had to perform. This was because of all the unexpected problems we had to face throughout the entire timeframe of development, which at the time were completely unlike anything we had faced before. Often, we had to rely on the open-source community which had previously done an amazing job at some React Native and blockchain libraries.

The issues

As an act of reciprocity, we'll guide you through some of the bigger issues we faced whilst developing the application. Also worth mentioning, the list below is still work in progress as we're certain further issues will pop up every day, from Operating System updates to the deprecation of some libraries we've used, as well as potential security vulnerabilities which may arise.

JavaScriptCore

If you have past experience with React Native, it's likely you'll know that it runs a specific version of the JavaScript Engine – JavaScriptCore, which Safari is built on.

Therefore, as some JavaScript functions are not yet available in JavaScriptCore, naturally as a consequence, some of the most popular JavaScript packages relevant for this kind of product – such as generating wallets or broadcasting transactions to the network – to this date, are not yet available in JavaScriptCore, meaning it's not ready to be used with React Native.

However, such packages are available for NodeJs instead. Initially, what could have been a nightmare turned out plausible – once more, with the help of the community, we got to some workarounds which made possible bringing those functions from NodeJS to React Native.

Technical debt

Things like hierarchical deterministic wallet, BIP32, BIP44, WIF, private key, address keys, lightning network, just to mention a few amongst other subjects you probably haven't heard of.

Perhaps these may – or may not – be the sole reason why one hasn't built a thing on top of the blockchain technology.

Even though throughout this journey, we found a lot of articles, videos, talks, crash courses, and documentation which provided us with the required information to understand the basics of the blockchain infrastructure, the practical reality is utterly different. In fact, the community lacks realistic examples on how to build applications for the real world, especially on popular languages for the web, such as JavaScript – which on its own is not so popular within the blockchain universe.

Asset implementation

Most crypto assets require their own dedicated implementation. Moreover, each requires dedicated libraries and/or frameworks to connect JavaScript and blockchain technology.

Depending on how many cryptocurrencies any given product is meant to support, the complexity may increase. In fact, there's not a one-size-fits-all when it comes to crypto assets. Almost each of them requires a dedicated, standalone process to get the connectivity going. Truth be told, have in mind that you'll have to implement one asset at a time while making sure it has JavaScript support.

In short, there isn't a single solution that covers every single cryptocurrency out there, at least when the goal is to remain decentralized. Even though you might – correctly – assume a big portion of the assets are built on the same infrastructure – extended from others, per se – every single one of them will require basic implementation and adaptation from previously integrated assets.

Public code validation

It isn't necessarily a rule, neither is this compulsory, but users withing the blockchain community are keen to validate application codebases before putting any extra effort into it, making sure such applications are secure and trustworthy.

Therefore, keep in mind it might make sense to Open-source the code at some point. It will be scrutinised by its users, but that's just a good thing – you'll push yourself towards a better, well-documented codebase.

On the flip-side of the coin, make sure all sensitive data or non-meant-to-be-public information is safely located somewhere else and not exposed.

Security - responsibility

People's money is on the line with these kinds of applications. Naturally, security is a fundamental concern when developing financial applications.

Users will be performing transactions, storing wallets' access keys, and even generating new ones. Due to the nature of these products, development must be responsible and lucid as every decision matters – even those that sometimes seem like no-brainers may be extremely relevant when it comes to security. Bottom line, there are no dumb questions or obvious answers when security and money are on the line.

On top of this, as you might have guessed by now, Open-source codebases can become an issue if you're not careful enough. Be extra careful when adding third-party party dependencies, beware of vulnerabilities or security breaches.

It's also worth pointing out that you should keep in mind that React Native and regular ReactJS – or the entire web environment as a whole – are deeply different at some point. A straight-forward issue on the web might be trickier than expected to deal with on React Native. For example, when developing these kinds of products, as you know, data must be stored locally on the device. For that matter, it must be placed in a safe, concealed place in order to avoid exposure to malicious users. With regards to this, make sure you choose the right approach to deal with the right kind of data.

One possible approach

There isn't a shortcut when it comes to developing React Native Apps in the blockchain. A lot of issues were solved, but a lot more will arise. That's just the nature of new technologies, nobody is 100% certain. There isn't a formula to help you smooth your way through this kind of project, there's just too much to consider and too many variables in the mix.

However, there are some points we've learned with this experience which we can recommend for you to take a look at:

Codebase reliability: make sure the codebase is type-safe, has great test coverage, handles errors properly, and is built on top of an architecture prepared to be scaled. Languages like Typescript or a tool like Flow will definitely help you on this path;
Security-driven development: keep all dependencies up-to-date. More often than not, security issues are identified and to tackle that, new package versions are released. Also, have a careful, thorough look at each package or library before settling for a specific one: see Open and Closed issues, how many projects are using it, who else is using it too, which dependencies are being made use of, and so forth.
Try. Start small, aim big: on the very first stage, take enough time to learn more about blockchain and how to implement it. There's a lot of content available out there, make sure you know where to start your research and, above all, what to search for. Don't hold back on moving on if you feel like so. Learning will come from the mistakes you make. Nevertheless, start small, aim big. Start with some small code samples to try out some basic concepts before moving on to the hardcore stuff.
Open-source, open mindset: Share your code with the community and ask for feedback. Let more experienced developers help you out. You may be or you may become more experienced than others, and for this matter, spread your knowledge, help them as well. Write articles, open-source your code, help other people grow. There are still a whole lot of unanswered topics when it comes to blockchain - jump-start discussions, call blockchain experts, make sure you're on the right path to help make sure others are on the right path.

Bottom line, we faced a bunch of problems while developing a Cryptocurrency App in the Blockchain using React Native. It had its ups and downs, but in the end, it was extremely rewarding. We've learned a lot with our own mistakes, we spent hours figuring out one single deployment, but in the end, the whole thing got sorted. We hope we're paving the way for those who follow.

In case you have any questions or facing any issues, feel free to get in touch with us.

Originally published at danilowoz.com