Forem: Iván García

4 folder structures to organize your React & React Native project

Iván García — Mon, 08 Feb 2021 19:03:21 +0000

When we start to develop a project with a new language or framework, one of the first questions that arise is how I organize my project and, in the case of React, this is no exception.

If we rely on the official documentation, React does not define a correct way to organize our files and leaves it to the discretion of the developer. This may seem strange if we have previously worked with frameworks such as Angular, but we must bear in mind that React is a frontend library that can be used both to create complete applications, as well as for specific components within an existing code base.

However, they do offer a couple of examples of popularly used structures. These are the file type based structure and the feature based structure. Unfortunately, the variants they show fall short and don't cover even the simplest project.

In this article we are going to see 4 ways to organize and structure React and React Native projects and we will give our opinion about them.

Structure based on file type

If you are starting to use React, it is most likely that you will start with an organization based on file type where most of the files are located inside folders with the name of each type and that are at the root level of our project.

This organization allows us to have a very simple structure for projects that are starting and it is the one that I would recommend for all those who start with React. The main problem is that once our project starts to grow, it can become a real chaos, especially at the component level, since in the simplest variant we would have them all inside a components folder.

That's why the version I like the most for this type of organization is the one that differentiates between components and pages. In this way, at the root level we would have a components folder for shared components, and in the pages folder each page would contain the main view and the components that are only used on that page. With this variation this structure scales much better and we can take it to much larger projects.

src/
|-- components/
|   |-- Avatar/
|   |   |-- Avatar.jsx
|   |   |-- Avatar.test.js
|   |-- Button/
|   |   |-- Button.jsx
|   |   |-- Button.test.js
|   |-- TextField/
|   |   |-- TextField.jsx
|   |   |-- TextField.test.js
|-- contexts/
|   |-- UserContext/
|   |   |-- UserContext.js
|-- hooks/
|   |-- useMediaQuery/
|   |   |-- useMediaQuery.js
|-- pages/
|   |-- UserProfile/
|   |   |-- components/
|   |   |   |-- SomeUserProfileComponent/
|   |   |   |   |-- SomeUserProfileComponent.jsx
|   |   |   |   |-- SomeUserProfileComponent.test.js
|   |   |-- UserProfile.jsx
|   |   |-- UserProfile.test.js
|   |-- index.js
|-- routes/
|   |-- routes.jsx
|   |-- routes.test.js
|-- utils/
|   |-- some-util/
|   |   |-- index.js
|   |   |-- someUtil.js
|   |   |-- index.test.js
|-- services/
|   |-- some-service/
|   |   |-- index.js/
|   |   |-- someService.js/
|   |   |-- index.test.js
|-- App.jsx
|-- index.js

As we can see in the example, this structure is very intuitive for anyone who reviews our code, that is why it is the organization that is most often used when starting with React.

Modular structure or feature based

The next method of organization mentioned in the documentation is the feature based one. This structure is interesting for projects with a larger scale.

The main idea is that each module we define has all the code related to it and only code from the module itself is imported. When we have several modules that need the same piece of code, we can write it into a shared folder and import it into the different modules. The fundamental rule to be followed is not to import code between modules.

src/
|-- components/
|   |-- Avatar/
|   |   |-- Avatar.jsx
|   |   |-- Avatar.test.js
|   |-- Button/
|   |   |-- Button.jsx
|   |   |-- Button.test.js
|   |-- TextField/
|   |   |-- TextField.jsx
|   |   |-- TextField.test.js
|-- contexts/
|   |-- UserContext/
|   |   |-- UserContext.js
|-- hooks/
|   |-- useMediaQuery/
|   |   |-- useMediaQuery.js
|-- features/
|   |-- Home/
|   |   |-- components/
|   |   |   |-- SomeUserProfileComponent/
|   |   |   |   |-- SomeUserProfileComponent.jsx
|   |   |   |   |-- SomeUserProfileComponent.test.js
|   |   |-- utils/
|   |   |-- services/
|   |   |-- hooks/
|   |   |-- contexts/
|   |   |-- views/
|   |   |   |-- HomeView.jsx
|   |   |-- pages/
|   |   |   |-- HomePage.jsx
|   |-- index.js
|-- utils/
|   |-- some-common-util/
|   |   |-- index.js/
|   |   |-- index.test.js
|-- services/
|   |-- some-common-service/
|   |   |-- index.js/
|   |   |-- some-common-service.js/
|   |   |-- index.test.js
|-- App.jsx
|-- index.js

The main ideas behind this method of organization are based on the concepts explained in Domain Driven Design applied for a long time in the backend. The great drawback of this structure is that it can be complex to define what a module is and this can has a great impact on the success of our organization.

Structure based on Atomic Design

Once the structures based on features and file type have been covered, another concept that often appears is that of Atomic Design. This is a methodology for creating design systems developed by Brad Frost and Dave Olsen and it is not unique to React, but it fits very well with the library due to the way of creating component-based interfaces.

Atomic Design is not a complete method of structuring our project, but a way of organizing our components. Therefore it would be more of a pattern that we can apply within our existing organization.

The main idea is to divide our components into five types of elements:

Atoms
Molecules
Organisms
Templates
Pages

If we apply this in the two structures that we have seen, they would look as follows:

File type based

src/
|-- components/
|    |- atoms/
|  |  |-- Button/
|    |  |   |-- Button.jsx
|    |  |   |-- Button.test.js
|  |- molecules
|  |- organisms
|  |- templates
|-- contexts/
|   |-- UserContext/
|   |   |-- UserContext.js
|-- hooks/
|   |-- useMediaQuery/
|   |   |-- useMediaQuery.js
|-- pages/
|   |-- UserProfile/
|   |   |-- components/
|   |   |   |-- SomeUserProfileComponent/
|   |   |   |   |-- SomeUserProfileComponent.jsx
|   |   |   |   |-- SomeUserProfileComponent.test.js
|   |   |-- UserProfile.jsx
|   |   |-- UserProfile.test.js
|   |-- index.js
|-- routes/
|   |-- routes.jsx
|   |-- routes.test.js
|-- utils/
|   |-- some-util/
|   |   |-- index.js
|   |   |-- someUtil.js
|   |   |-- index.test.js
|-- services/
|   |-- some-service/
|   |   |-- index.js/
|   |   |-- someService.js/
|   |   |-- index.test.js
|-- App.jsx
|-- index.js

Feature based

src/
|-- components/
|    |- atoms/
|  |  |-- Button/
|    |  |   |-- Button.jsx
|    |  |   |-- Button.test.js
|  |- molecules
|  |- organisms
|  |- templates
|-- contexts/
|   |-- UserContext/
|   |   |-- UserContext.js
|-- hooks/
|   |-- useMediaQuery/
|   |   |-- useMediaQuery.js
|-- features/
|   |-- Home/
|   |   |-- atoms/
|   |   |-- molecules/
|   |   |-- organisms/
|   |   |-- utils/
|   |   |-- services/
|   |   |-- hooks/
|   |   |-- contexts/
|   |   |-- pages/
|   |   |   |-- HomePage.jsx
|   |-- index.js
|-- utils/
|   |-- some-common-util/
|   |   |-- index.js/
|   |   |-- index.test.js
|-- services/
|   |-- some-common-service/
|   |   |-- index.js/
|   |   |-- some-common-service.js/
|   |   |-- index.test.js
|-- App.jsx
|-- index.js

The truth is that when I've had the chance to use Atomic Design in a React project, it has not convinced me. Personally, the main drawback is that you have to learn to categorize each type of element and this is fine if the whole team knows the methodology but otherwise it can create more problems than it solves.

Even so, if your team is used to working with this methodology or you are looking for a new way to organize the projects and you like the ideas described by Brad's method, it is a very good way not only to structure the code in our application, but even to structure our own design system in applications like Figma.

Structure based on hexagonal architecture

Finally, I would like to mention the structure based on the hexagonal architecture. This is the only one that I have not used at the moment but I find it very interesting, especially if the team is Full-Stack and is used to work with this architecture on the backend.

This is the most complex organization of all that we have seen and bases its ideas on the architecture developed by Alistair Cockburn. In this article we are only going to show an example of how look like applied to a React project, but there are a lot of resources out there to dig deeper.

src/
|-- domain/
|   |-- models/
|   |   |-- User.js/
|   |-- services/
|   |   |-- User.service.js/
|-- infrastructure/
|       |-- components/
|       |   |-- Avatar/
|       |   |   |-- Avatar.jsx
|       |   |   |-- Avatar.test.js
|       |     |-- UserProfile/
|       |   |   |-- UserProfile.jsx
|       |   |   |-- UserProfile.test.js
|       |-- http/
|       |   |-- dto/
|       |   |   |-- userDto.js/
|       |   |-- http.js
|       |-- repositories/
|       |   |-- user.repository.js/
|-- App.jsx
|-- index.js

As we see at first glance, if we have never dealt with the hexagonal architecture it can be quite complex to understand where each part of our code is. I would only use this structure in case that we are used to work with it in our backend and we want to maintain the same architecture on the frontend. If not, I do believe that the ones we have seen in the previous points are more recommended for most projects.

Conclusions

As we can see there are many ways to organize our code from the simplest to the most complex. A simple way of organization does not have to be worse than a complex one, it all depends on the size of our code base and the size of the team that manages it.

How to use Google Apps Script to automate processes in your company at no cost

Iván García — Tue, 05 Jan 2021 13:47:59 +0000

Within the collection of tools and services that we use both in the Studio and in some of our own products, Google App Scripts is one of our favorites. This tool allows us to automate recurring tasks and processes for free by interacting with Google services such as Google Sheets, Docs, Drive etc.

Getting started with Google App Scripts

To create our first script we can do it by accessing the Google Apps Script page. This is the main page of the tool where we will see all the scripts created, the logs of the executions and the associated triggers.

We can also create a script directly from the Google tool to which we want to associate it, in the case of Sheets we can do it by clicking on Tools → Script editor.

This will open a development environment in the cloud where the script code can be written and executed directly.

Now that we know how to create a script, we are going to learn through two examples the basic functionalities that will allow us to start creating automatic processes.

Script to update currencies in Billbot

The first example that we are going to cover is a script that we use to obtain and format the list of currencies that we use in Billbot app that we created in the Studio.

The first thing we have to solve is how to make a request to an API from the script. For this it will be necessary to use the class UrlFetchApp that will allow us to do it and it's one of the most useful methods that AppScripts have.

In our case, we not only need to make one request, but multiple ones, given the structure of the data that the API returns. For this we will use the fetchAll method that allows us to make multiple requests at the same time.

Here is how the code looks like:

function myFunction() {
  var API = 'API_URL';
  var EUR = API + '&base=EUR';
  var USD = API + '&base=USD';
  var GBP = API + '&base=GBP';
  var CAD = API + '&base=CAD';
  var AUD = API + '&base=AUD';
  var CHF = API + '&base=CHF';
  var MXN = API + '&base=MXN';
  var RUB = API + '&base=RUB';
  var INR = API + '&base=INR';
  var BRL = API + '&base=BRL';
  var DKK = API + '&base=DKK';
  var SEK = API + '&base=SEK';
  var NOK = API + '&base=NOK';
  var HRK = API + '&base=HRK';
  var NZD = API + '&base=NZD';
  var CZK = API + '&base=CZK';
  var JPY = API + '&base=JPY';
  var PLN = API + '&base=PLN';
  var RON = API + '&base=RON';
  var THB = API + '&base=THB';
  var AED = API + '&base=AED';
  var HKD = API + '&base=HKD';
  var HUF = API + '&base=HUF';
  var ILS = API + '&base=ILS';
  var SGD = API + '&base=SGD';
  var TRY = API + '&base=TRY';
  var ZAR = API + '&base=ZAR';
  var SAR = API + '&base=SAR';
  var BGN = API + '&base=BGN';
  var QAR = API + '&base=QAR';
  var ISK = API + '&base=ISK';
  var MAD = API + '&base=MAD';
  var RSD = API + '&base=RSD';
  var ARS = API + '&base=ARS';
  var BHD = API + '&base=BHD';
  var BOB = API + '&base=BOB';
  var CLP = API + '&base=CLP';
  var CNY = API + '&base=CNY';
  var COP = API + '&base=COP';
  var EGP = API + '&base=EGP';
  var IDR = API + '&base=IDR';
  var KRW = API + '&base=KRW';
  var PEN = API + '&base=PEN';
  var PHP = API + '&base=PHP';
  var UAH = API + '&base=UAH';
  var UYU = API + '&base=UYU';
  var GTQ = API + '&base=GTQ';
  var PYG = API + '&base=PYG';

  var response = UrlFetchApp.fetchAll([
    EUR,
    USD,
    GBP,
    CAD,
    AUD,
    CHF,
    MXN,
    RUB,
    INR,
    BRL,
    DKK,
    SEK,
    NOK,
    HRK,
    NZD,
    CZK,
    JPY,
    PLN,
    RON,
    THB,
    AED,
    HKD,
    HUF,
    ILS,
    SGD,
    TRY,
    ZAR,
    SAR,
    BGN,
    QAR,
    ISK,
    MAD,
    RSD,
    ARS,
    BHD,
    BOB,
    CLP,
    CNY,
    COP,
    EGP,
    IDR,
    KRW,
    PEN,
    PHP,
    UAH,
    UYU,
    GTQ,
    PYG,
  ]);

    Logger.log(response);
}

In order to see the results of the request we can use Logger.log. This would be the equivalent of the JavaScript console.log but it will allow us to see the results in the App Scripts debugger. To see the records we can press ctrl + Enter on the keyboard or cmd if you are on Mac.

Once we have the data fetched, the next step is to format it as we want. For this we will simply use a JavaScript reduce and we will convert the result of it into a string.

var data = response.reduce(function (previous, current) {
    var currentJson = JSON.parse(current);
    var currencyData = currentJson.rates;
    var currency = currentJson.base;
    var currencyDataWithBase = { ...currencyData, [currency]: 1 };

    return { ...previous, [currency]: currencyDataWithBase };
}, {});

var dataParsed = JSON.stringify(data)

Once the data is formatted we need to store it in the spreadsheet. This can be done using the SpreadSheetApp class. The essential methods of this class are getActive(), which allows us to take the reference of the file to which the script is associated, and getSheetByName(), which allow us to establish the reference of the specific sheet of the associated file.

Once we have the reference of the sheet in a variable, we can use it to read and store data within its rows and columns. With the getRange and setValue methods we can write inside the cell, and with the getValue method we will obtain the value found in it.

Specifically, in our script we want to store all the data obtained in the first cell of the spreadsheet, so we can achieve this with these four lines of code.

var ratesSpreadSheet = SpreadsheetApp.getActive();
var dbSheet = ratesSpreadSheet.getSheetByName('db');

dbSheet.getRange(1, 1).setValue(dataParsed);
SpreadsheetApp.flush();

Once the script is executed we will find the output on the cell 1,1 of our spreadsheet. We can see that is filled with the data obtained from the API and formatted with our needs.

Only by making use of the Logger, SpreadSheetApp and UrlFetchApp classes that we have just seen, we can create very powerful scripts with some knowledge of JavaScript and some creativity. The following example is a clear case of this: with the use of these three APIs we built a system for creating automatic invoices for our startup.

Cravy Partners billing system

In Cravy every week we had to create invoices for the restaurants that were partners of our platform. Initially we started creating them manually with a Google spreadsheet that we converted to pdf. When we had more than 10 restaurants, the process was quite tedious and could take a whole day of work.

Each restaurant had two documents: the invoice with the commission for our service and a receipt with all the orders associated with that commission.

Taking advantage of the fact that we already had the invoice template and total control over the database and the backend of the project, we decided to create an App Script that would do the following:

Create a folder with the current date to store documents in Google Drive in an organized way.
Obtain orders information for each restaurant by making a request to the backend.
Create a copy of the Google Sheets templates for each restaurant and fill them with the information obtained from the API.
Store the created copies in the corresponding folder and create a PDF version of the file.

In this article we are going to focus on showing the most interesting options that the API provides us and we will not go into detail about the logic of the script itself, but if you want to see the complete script it can be found on Github.

Creation of the folder in Google Drive

One of the classes that we have not seen yet is DriveApp, which allows us to perform operations on Google Drive folders and files.

In our case we want to create a new folder with the date as the name within a specific Google Drive folder.

  const now = new Date();
  const billDay = new Date(now.setDate(now.getDate() + 1))
    .toISOString()
    .slice(0, 10);

// Creating the day folder to save the bills
  const folderId = DriveApp.getFolderById('FOLDER-ID')
    .createFolder(billDay)
    .getId();

The FOLDER-ID can be found at the end of the url slug when we are inside the folder as we can see in the image.

Create a copy of the Google Sheets templates for each restaurant

In order to create a spreadsheet for each restaurant, what we do is to execute the function for each of the restaurants that we have. We can do this through a simple for.

for (var index = 0; index < restaurantsData.length; index++) {
    fillSheetWithBillingData(
      restaurantsData[index],
      billDay,
      firstDay,
      lastDay,
      folderId
    );
  }

Once the function is executed, it requests the restaurant information from the backend using the UrlFetchApp class as we have seen in the Billbot example, and we do the necessary operations in JavaScript to obtain the data in the format we want.

Once we have this data we proceed to create the new spreadsheet using the following lines of code.

//Setting the reference to the original sheets
var billSheet = originalSpreadsheet.getSheetByName('Bill');
var ordersBillSheet = originalSpreadsheet.getSheetByName('OrdersBill');

//Create new restaurant sheet
var newBillSheet = SpreadsheetApp.create(
      'Factura-' + restaurantName + '-' + billDay + ''
    );
var newOrdersBillSheet = SpreadsheetApp.create(
      'Annnexo-' + restaurantName + '-' + billDay + ''
    );

//Copy the parent sheet content to the new created sheets
billSheet.copyTo(newBillSheet);
ordersBillSheet.copyTo(newOrdersBillSheet);

Using the create() and copyTo() functions we create two new empty spreadsheets and then copy the content of the spreadsheet that serves as a template. Keep in mind that this will create the files in the root folder of our Google Drive, so in the final step we will have to move these files to the corresponding folder and remove them from the root.

The next step of the script is to fill the spreadsheets we just created with the information obtained from the API using the getRange() and setValue() methods of the SpreadsheetApp class that we have seen in the previous example.

Store the copies created in the corresponding folder and create a PDF version of the file

Finally, the last step is to store the two spreadsheets created and export them as PDF. To do this we only need a small function.

function exportSomeSheets(
  restaurantName,
  folderId,
  newBillSheet,
  newOrdersBillSheet
) {
  // Save the files in to the correspondent folder
  var folder = DriveApp.getFolderById(folderId).createFolder(restaurantName);
  var copyNewBillSheet = DriveApp.getFileById(newBillSheet.getId());
  var copyNewOrdersBillSheet = DriveApp.getFileById(newOrdersBillSheet.getId());

  folder.addFile(copyNewBillSheet);
  folder.addFile(copyNewOrdersBillSheet);
  folder.createFile(copyNewBillSheet);
  folder.createFile(copyNewOrdersBillSheet);

  DriveApp.getRootFolder().removeFile(copyNewBillSheet);
  DriveApp.getRootFolder().removeFile(copyNewOrdersBillSheet);
}

The steps that this function performs are the following: first create a folder with the name of the restaurant inside the date folder generated in the previous step.

Then paste the spreadsheets from the second step into the folder with the name of the restaurant with the addFile() function. Last, it creates the pdf version with the createFile() function.

Finally we delete the files from the root folder to avoid accumulating them.

Conclusions

As we can see, with the App Script and our creativity we can do very powerful things that help us in the day to day of our company and save us hundreds of hours at the end of the month. These are just a couple of examples that we have implemented to automate certain parts of our operations, but the same can be applied to many more cases.

In addition, another advantage of using App Script is that it is a completely free service within the limits of the platform, so we can have cron jobs and other automatic processes at no cost.

How to create a marketplace with no-code in just a weekend

Iván García — Tue, 22 Dec 2020 20:44:31 +0000

At Reboot we wanted to create a project entirely with no-code for a long time and this weekend we had the opportunity to do it on the NoCode Fest organized by the good people of SharingAway.

The goal of the event was to create a digital product without programming during a weekend and to launch it on the market. As our goal was to explore the limits of no-code, we set out to create the most complex example that came to mind and decided to build a marketplace in one weekend.

Marketplaces are complex products, we know it first-hand because we spent 6 months building one at Cravy, so it seemed like a great product to test no-code capabilities. Have we succeeded?

The project

Spotanoffice is a marketplace that allows you to book spaces to work by paying a monthly subscription. Now that working remotely or working from home has come to stay, offering the possibility of choosing where you want to work seems like a great idea. This is what the guys from Tribu are working on, who also inspired us for the project.

The operation of the marketplace is very simple. On one side we have the spaces and on the other the users who book these spaces. Users can explore spaces based on criteria such as location, get information about their characteristics and make a booking for the desired date.

As in any marketplace, the rating and review system is very important to generate trust, so it is also necessary that a user can vote and add a review on the booked space.

Finally, as it is a fictional project, we have decided to create an original narrative around it and set it on known science fiction planets. So at Spotanoffice you can book a coworking on Mars, surf on Interstellar's Millet planet, or get to the office in a flying Uber on Pandora.

Project no-code stack

But let's get to the point: how did we manage to develop this product in a weekend? These are the tools we have used:

Webflow: website builder
Jetboost: search engine and space filter
Airtable: database
Memberstack: user authentication, subscription charging and creation of authenticated and unauthenticated environments
Integromat: creation of flows and functions for the different parts of the marketplace: user sign up, creation of a space, review system, etc ...
Sendgrid: email sending

Let's see in detail how they are connected and how we have used each of them.

Webflow

Webflow has been our tool to build the marketplace website. From the beginning we were clear that we wanted to create a unique design, so we discarded other solutions based on templates that limit you to work within their boundaries.

In this sense, Webflow is a fantastic tool. If you have knowledge of HTML and CSS you can create the web you want, the design is not a limitation. In addition, its visual interface allows you to be much more agile when we adjust our layout. Modifying paddings and margins and seeing how it changes in real time on our page is a real joy.

But the feature that allows Webflow to create really powerful websites is CMS Collections. With Collections we can replicate the data model that our project needs, relate them to each other and consume them dynamically from the pages.

Webflow automatically generates a page for each Collection from which we can consume the information or the related one. In our case, we have a Collection page for the spaces and the user profile. From these pages, related Collections such as reviews, rooms or reservations are also consumed.

However, in order to achieve the full potential that tools like Integromat gives you, we need this information not to be generated in Webflow but in Airtable, so it is automatically created or updated in Webflow every time we modify our Airtable.

Airtable

Airtable is our database where we create and update our spaces, services or rooms. Airtable replicates the data model that we have previously created in Webflow through the CMS Collections and, thanks to the magic of Integromat, allows creating and updating the information that we will show in Webflow dynamically.

But it is not the only thing we can do. The reason for using Airtable as a database is to incorporate it into specific product flows through Integromat. In this way, when a user makes a booking for a space, we could see if it is available for the selected dates by connecting Airtable and Integromat.

Memberstack

The next piece of our puzzle is Memberstack. This tool allows us several things:

Authentication. First of all, it allows us to register and authenticate users on our platform. By integrating a small script in Webflow we can open a modal that allows us to start registering users, logging in or managing the "Forget password".
Membership plans. The tool allows us to create different plans, both free and paid for our project. In this way, we can create a recurring payment plan or a single payment at the time of registering on the platform and thus be able to start charging our users.
Creation of authenticated environments. With Memberstack we can also create authenticated environments that can only be accessed with a specific plan. For example, in our case, the user profile page where the bookings are shown is only accessible once you are registered. This is made in a very simple way through links and attributes that the platform itself generates.
View content for members only. Finally, we can also hide or show content dynamically depending on whether the user is registered or has a specific plan.

Integromat

Integromat is the glue that holds all the tools together. The functions of our product. It would be the backend in any code project.

At Integromat we can create scenarios for each product flow we have. These are some of the ones we have created for Spotanoffice:

Booking system
User Sign Up
Rating System
Create Space
Update Space

Let's see in more detail how a specific flow like the Booking system works:

Sending the booking form in Webflow triggers the flow through a webhook.
We check that it is a booking type form.
We check in Airtable that both the user who is making the booking and the space exist.
We create the booking of the space in Webflow.
We create the booking of the space in Airtable with the ID of Webflow.
We update the Webflow user to include the space booking.
Finally we send a confirmation email with Sendgrid to the user.

Result

We have had a great time participating in this first edition of the NoCode Fest and we would like to congratulate the entire SharingAway team for the magnificent organization. It's amazing how you can create complex digital products like a marketplace in just one weekend, with a small stack of tools and making the right tradeoffs.

No-code is a very powerful tool to empower entire teams and organizations, prototyping faster, cheaper, and getting to market in less time. We invite you all to discover Spotanoffice and leave us your feedback.

Spotanoffice

If you are considering using no-code for your product, at Reboot we can help you define the strategy, the stack of tools and set the necessary tradeoffs to be able to launch a first prototype to the market in an agile way.

Mobile App vs Web: Which to develop first?

Iván García — Mon, 14 Dec 2020 19:03:11 +0000

Choosing well the platform on which to build your project is not a minor issue and has a clear impact on the business. Making the decision to start with a web or an app is still a real headache for many startups and companies that start their digital project.

In Reboot we see many of these cases often and, furthermore, we have had to face these questions several times in the past: What is best for my project: starting with a web or an app?

Today we want to share with you some key points that will help you to reflect and make the right decision in your case.

Business model

As we have already discussed in previous articles, the business largely determines the product.

We must understand how our project is going to generate income and what is the model behind it. For example, if it is a model based on a high recurrence and repetition by the user, surely we are interested in exploring the creation of an app.

This is clearly the case for mobile games that need to create that habit in the player through instant access and reward. From here, they can monetize through advertising or in-app purchases, but in both cases it is necessary to create that daily recurrence in the player that only mobile apps can do.

However, games are not the only products with a business model based on high recurrence. Certain marketplaces such as Uber (ride-hailing) or Deliveroo (food delivery) also adopted mobile applications from the first moment due to the high recurrence of their model.

On the other hand, if recurrence is not a key factor in your business model, you can surely start with a website, many ecommerce are in this category.

In summary:

If your business model aspires to a recurrence of less than 1 week, a mobile application makes a lot of sense
If your business model has a recurrence of more than 1 week, a website is probably the best option

Distribution

Once we are clear about how we make money and what type of model our business is defined, we have to talk about distribution. Distribution determines the channels through which we will deliver our product to the user or customer.

Building an app or a website will determine what channels we have available to distribute our product, so it is very important to detect that we are not ruling out a channel that may be vital for our business.

Friction

Firstly, we must know that generating a download for our app will normally be more difficult - and therefore more expensive - than generating a visit to our website. This is simply due to the friction that one process requires over another. To get a download we need the user to enter the store, have enough space on their device and pass their evaluation of whether it is worth installing a new app.

Instead, it is easier to direct traffic to a website simply through its link. The friction is much lower and the cognitive effort required from the user is also less.

Agility

The agility and speed of distribution is also an important point to take into account. Currently, the applications are distributed through the two main stores: App Store for iOS and Google Play for Android. This means that any change we make not only implies generating a new version of our app, but it must pass the filter of the two platforms before it is available to users.

This translates into time. Time to generate new versions and approval time by stores, which varies from the App Store or Google Play but is usually between 1 and 3 business days for each new update.

If you need agility to be able to make quick changes, then you should definitely build a website where you can control the speed of distribution and be able to perform hot-fixes in a matter of minutes and not days.

Channels

What will be the main distribution channels? Let's see some of them and their incidence if it is a web or app.

SEO. If search engine optimization is one of the main channels then we need to build our product on the web. It is true that ASO exists for app store optimization, but it is much less actionable and predictable than SEO.
SEM. In the same way, if SEM is important for the distribution of your product, it is best to start on the web. As with SEO, there is also the corresponding version of the SEM for app stores where we can bid on certain keywords, but it does not have the same depth or scope as the browser version.
Performance Marketing. Ads work very well whether our product is web or app and, although the installation cost is higher than the simple click, it should not be a reason to discard any of both.
B2B / Partnerships. If the main channel is direct sales or partnerships, we should assess other aspects to finally opt for the web or app.

Target audience

The type of user we are targeting is also a factor to take into account. How old are they? What are their habits? In what kind of environment do they operate and where does my product fit? For example, they may work in a desktop environment, but at home and for leisure, their use is mainly mobile. Is our product focused on work or leisure hours?

Obtaining a complete X-ray of our user will allow us to determine if an app or a web fits better with their habits and customs. We must not confuse customer with user, many times these two facets occur in the same person but it does not always have to be this way. For example, the customer of our product may be the company but the user its workers.

Resources

The resources we have for our project is also a factor that will determine our final decision. Generally, the cost of developing an app is usually higher than a website. There are so many reasons for that, one of them is that there are many more tools, solutions and frameworks on the web to do certain things that prevent us from starting from scratch.

Of course, both an app and a website are much more than the user can see and there are common parts that have to be developed equally in both cases, such as the backend, the database or the administration panel if required.

Speaking of costs, we also have to take into account the fee we have to pay to app stores when we sell digital assets. In the case of Apple it is 15% if we invoice less than 1 million per year and 30% in the case of the Play Store.

Fortunately, the cost factor is less and less relevant when we decide between web or app thanks to frameworks such as React Native or Flutter that are managing to close the circle between web and mobile development.

User experience

Last but not least, the user experience is also essential and this will be defined by the type of product we are building.

Let's start with an easy case: games. If your product is a game you need an app. There's no other way. You need to offer an immediate, responsive, latency-free experience that can make use of the device's resources.

Does every business need this kind of native experience? Absolutely not. Nowadays you can create great products on the web that can even have access to certain native functions of the system such as geolocation or the camera. For this reason, it is very important to plan a Mobile First experience from the beginning, so that not only the web is perfectly usable from mobile devices, but also that its experience is as close as possible to that of a native app.

In fact, in this direction we find the PWAs (Progressive Web Apps) that companies like Aliexpress or Twitter are already using. PWAs are halfway between web pages and mobile applications and, thanks to the use of Service Workers and other technologies, they achieve an experience closer to that of a mobile app.

It is even possible to install a PWA as you would do with an app and perform tasks that were previously only reserved for native apps, such as receiving notifications or working without an Internet connection.

Conclusions

Ultimately, the choice to build our product on the web or in an app is essential as it has a direct impact on our business model, the way in which we will attract users, how much these users will cost us, how many resources we should have or what kind of experiences we can offer.

At Reboot we can help you with this and many other questions that usually arise before starting the development of a digital product, defining together a first version that validates business hypotheses but also offers an appropriate user experience.

We solve problems, we don't write code

Iván García — Tue, 08 Dec 2020 11:45:48 +0000

We love writing code, but we try to avoid having to. Our vocation is to create products that solve problems and how to create them must always be aligned with the problem we want to solve and the available resources. Writing code should be the means, but never an end in itself.

As technical people it is easy to be tempted to customize each solution, write a lot of code and create true "tailored suits". However, technology is only one of the pieces that make up a product, not the only one. Design is just as important and we talked about it in a previous article. And today we present the third and final piece: the business.

Do you know what the core of your business is?

Understanding the core of our business will allow us to identify the tools that we will use to build the product and prioritize our efforts. Sometimes it will be a SaaS that perfectly solves one of the parts of the product, in others it will be existing platforms or frameworks that will allow us to speed up its creation and, indeed, there will be times where we will have to write code.

It is almost as important to understand what the core of your business is, as it is to understand everything that is not. Is processing payments the core of my business? Is the infrastructure the core of my business? Is sending emails the core of my business? The answer to these questions will help you order and prioritize efforts in each area of your product.

Be careful, that it is not the core of the business does not mean that it is not important. It simply means that it is not differential, only necessary. If you have an online store, being able to accept payments is not differential, it is necessary. Even the platform of your store is not differential but necessary to be able to sell. On the other hand, the product, distribution and marketing are unique and differential factors for the success of your store.

Many times this process can be simplified into a single question: Is this going to determine the success of my business? For example: Will developing a custom solution for sending emails versus using an existing service like SendGrid determine the success of my online store? If the answer is "no" we may be misaligning resources and efforts at the core of the business.

Cases that we find in Reboot

1. Lead capture landing

A common project that we work with from the Studio is that of a startup or company that needs a landing to advertise its product or service and to be able to capture leads from interested people.

In these cases our priorities are usually:

Design and narrative
Empower the team
Performance

Each of these objectives determines what technologies and tools we will use to build the landing.

The objective here is clearly to sell the product or service, so we have to be able to create a landing with a design and narrative that differentiates, persuades, generates trust and interest. Therefore, we need full freedom to execute our design, avoiding template systems or drag-and-drop editors of doubtful quality.
Second, we need a solution that does not limit but empowers the promoter team of the project. The product and discourse will surely evolve over time and we need to provide the autonomy to be able to translate these changes without creating a dependency on the studio, agency or technical team. This may be seen as a bad business decision as a product study, but it is completely aligned with our values.
Finally, we need a landing that simply works under any circumstance, without transferring to the team the typical problems of infrastructure, servers, availability, among others.

So ... what would be our proposal for this case?

Webflow would be our entry solution to build the landing. It offers absolute freedom for the execution of the design, allows to make changes in a very intuitive way thanks to its editor and abstracts the team from the mentioned problems of performance, hosting and availability. As an alternative, we have also sometimes recommended developing a custom frontend with Next.js and integrating a HeadlessCMS for copy and content management.
Typeform for capturing leads when you want to create complex, personalized forms with a good user experience. It is also possible to use the form tool that integrates the Webflow for these cases.

2. Ecommerce

The technology to start an online store today is already a "commodity". It is not even necessary to have technical knowledge to do it, although many still try to continue reinventing the wheel.

The challenge of the project is to understand well the particularities of the product to be sold and to offer the best option based on this.

Shopify is usually our preferred ecommerce solution for the vast majority of cases. Tested and verified by millions of brands that every day sell hundreds of millions of dollars on the platform, with thousands of integrations available at a single click from the store and, again, completely abstracting the hosting and performance layer and giving us a cloud solution that "it just works". Sometimes we can also explore other platforms such as BigCommerce.
When design, customization and branding have a very important weight we recommend creating a storefront. A storefront is an independent website that integrates with your ecommerce in order to display products in a unique and differential way. For us, it offers the best of both worlds: the robustness and reliability of an ecommerce platform like Shopify with the freedom and flexibility to create a unique web experience.

It is not about reinventing the wheel, the technology to create and launch e-commerce is already here, so our job should be to understand the business and its peculiarities, and offer the best solution for it.

The problem, again, is that this often works against the business as a studio / agency / service provider. Sometimes reinventing the wheel is the only way to justify an exaggerated budget and number of hours. Of course, this is not the way we do business at Studio and it never will be.

3. Infrastructure without DevOps

Finally, infrastructure is usually one of the main headaches of any project. Ensuring that our product is available and accessible at any time for users is essential, but we are not specialists in Infrastructure. How do we do it then?

In our case we rely on PaaS (Platform as a Service) such as Heroku, Render or Vercel for the deployment of all the projects that we develop in the Studio. These are some of the reasons:

Predictability. You know how much you are going to pay at the end of the month, something essential for any business.
Scalability. If your product requires it, these platforms can scale the resources according to your specific needs.
Simplicity. Being able to have different development environments easily, being able to make quick deployments by pushing the project repository without having to connect to an FTP.
Intuitive. It is very easy to enter the panel of any of these services and understand the status of your product: if it is deployed, perform a rollback to a previous version if something has gone wrong, etc.
They are not lock-in. When your product matures and requires a more complex infrastructure, you can stop using these services and switch to your own solution in any other service.

Conclusions

In short, we are dedicated to building products that are framed in specific technology, design and business needs. You can't create good products if you don't consider any of the above. It must be understood from the honesty to propose the best solution for the client's challenge, although sometimes this is not the best decision for your treasury.

Product work never ends, it is a constant process of learning, iteration and experimentation. The tools and technologies with which the product is built can also evolve. They must evolve. And our process contemplates offering the best solution for each stage, avoiding premature oversizing, but being prepared to scale when necessary.

🚀 We are live on Product Hunt - TOP #3

Iván García — Sat, 28 Nov 2020 10:26:37 +0000

Hey guys!

We are really excited to launch our side-project on Product Hunt. Billbot is an app to manage your subscriptions and regular expenses with ease.

Here's a highlight of some of Billbot's best features so far:

♾️Unlimited subscriptions: Add as subscriptions and expenses as you need with no limits
📲Android & iOS compatible
🔔Set reminders for your subscriptions to get notified before the due date
📦Create separate spaces to classify your expenses (home, personal, freelancing, etc...)
🎨Customize the accent color of your spaces and subscriptions... and add tones of emojis!
💶Convert your subscription value to 15 different currencies
🔥+200 popular templates ready to add with one tap
🌍Enjoy Billbot in 8 different languages: english, spanish, french, german, italian, portuguese, russian and hindi
💡Get insights on your regular costs

We would love to get your feedback and support 🙏

https://www.producthunt.com/posts/billbot

Why your business doesn't need a native app

Iván García — Tue, 17 Nov 2020 10:41:26 +0000

An important part of the projects that we have at Reboot are based on the development of a mobile application. When we meet the team, on many occasions they have certain preconceptions about why developing a native app is the best option.

We have a strong opinion on this issue: we believe that in the vast majority of cases your business does not need a native application. In fact, there are many false myths and misconceptions about so-called "hybrid development". Today we are going to try to disassemble some of them.

You will achieve a more economic development

This is usually one of the aspects that most businesses worry about when it comes to developing its own app. Developing an application is not cheap. There are many processes and tasks that must be taken care of to launch a quality product, but within this complexity the cost of cross-platform development is significantly lower than that of native development.

The reason is very simple: we have a single code base. This simplifies everything and, in terms of cost, it means that we will not need two specialist teams -iOS and Android- but we will only need a one specialist team in the language or framework in which we are working.

You will be able to ship your app faster

We must not forget that the goal of developing an app for our business is that we can put it in the hands of our customers. In this sense, go-to-market timing is essential, whether we are a startup or a large company. Every week that our app is not being used by our clients represents a very high opportunity cost.

Having a single code base for iOS and Android allows us to achieve much more reduced development times, since we do not have to multiply the work x2 on the two platforms that we want to launch.

In the end, everything translates into greater agility to launch, maintain and evolve our product. By having a single team in charge of the mobile application everything is greatly simplified, friction is reduced and the contribution of the whole team is improved.

Lower maintenance = less headaches

The advantages of having a single code base not only work in our favor in terms of costs and shorter development times. Once we have our app on the market we cannot forget about it, it must be maintained. This means, for example: keeping the libraries up to date, solving bugs and errors detected by users, incorporating new functionalities, etc ...

When we have a native application all our maintenance is multiplied x2. And that also affects the cost of such maintenance. Another possible problem is losing the person or persons in charge of one of the platforms.

When we centralize our application on a single team, it is easier to maintain it or find a replacement in an agile way. For example, if we use a web-based framework, it can be much easier to find web developers that we can migrate to mobile in less time.

Your app will have the same performance as a native app

One of the main fears of our clients when we ask them the option of developing their app with React Native is that it will "not work the same", "it will work slower" or directly "it will work badly". This is a very widespread myth, surely fed by companies that are interested in selling specialist profiles and thus being able to increase the final invoice.

Currently the frameworks that are used to develop mobile applications in a non-native way have evolved a lot. This belief that hybrid apps perform worse comes from the days when Ionic, Cordova, or PhoneGap were used.

Currently an application with React Native or Flutter offers the same performance as a native app in the vast majority of cases. Additionally, certain components can be developed natively to address specific performance issues. For example, here the guys at Shopify explain how they developed a native Bottom Sheet within an app with React Native.

Your users won't notice the difference with a native app

Another widespread false myth is that users will "notice" that it is not a native application. Here we enter directly into the realm of interface and interaction design. Many hybrid applications are developed without taking into account that iOS and Android have very different design guidelines.

A very common case is that of a company that develops a hybrid application using a library such as Material Design or basing the interface on Android's own navigation and interaction patterns. In this case it is clear that the iOS user will notice the difference and will know that something is wrong.

For this reason we do not conceive development and design independently. Although it is a single code base, the design, interaction and navigation have to be tailored to each platform.

Examples of popular non-native apps

This is all sounds well, but really who are using this hybrid approach in the market for their applications. Well, we really see that some of the largest technology companies in the world have already adopted this approach and the trend is that many more will join in the future.

In this list we find applications that will sound familiar to all of us:

Tencent uses Flutter throughout the company for several apps including AITeacher, Now Live, K12, Mr. Translator, QiDian, and DingDang.
Instagram uses React Native in some of the main app functionalities to be able to launch them in less time and test them with its large user base.
Tesla uses React Native for its main application with which to control the car and its status.
Discord uses React Native for the app on Android and iOS.
Shopify uses React Native in its new Shop application where you can buy and track your orders.
Skype uses React Native in its official application for Android and iOS.
Uber Eats uses React Native for its mobile application with which you can order, pay and track your order in real time.
Pinterest uses React Native in its official applications.

Frameworks for developing cross-platform apps

Today there are different frameworks for developing cross-platform applications. Some of the most adopted have large companies behind such as React Native with Facebook, Xamarin with Microsoft or more recently Flutter with Google.

React Native. This framework was created by Facebook and launched in 2015. It allows developing applications for Android, iOS, macOS, tvOS, AndroidTV and Windows using JavaScript and accessing the components and APIs of the system.
Flutter. It is an SDK created by Google and launched in 2017. It allows developing applications for Android, iOS and Web. It has the Flutter engine written in C ++ that provides low-level support for rendering. On the other hand we have the Foundation library written in Dart that provides basic classes and functions to develop our applications, as well as APIs to communicate with the Flutter engine.
Ionic. It was originally released in 2013 and is an open-source SDK created by Max Lynch, Ben Sperry and Adam Bradley of Drifty Co. The original version is built on top of AngularJS and Apache Cordova, but recently it was written from scratch to be based on Web Components, so the user can freely choose the framework to use in the front such as Angular, React or Vue.
Xamarin. Xamarin was the company created from the framework to which it gives its name and subsequently acquired by Microsoft. The framework is written in C # and allows you to create mobile applications for Android, iOS and Windows.

When develop a native app

Does this mean that it is never recommended to develop a native app? Absolutely not. According to our criteria, there are 3 scenarios where it makes sense to consider native development.

Apps that demand a lot of resources and performance. Here we are talking about 5% of the apps that need to access graphical system resources intensively, such as games or process a large volume of data.
When you already have a team or experience in native development. If this is your case, it may make sense to take advantage of that knowledge to develop and launch the project more quickly.
If you are very clear that your app will only be on a specific platform.

Conclusions

At Reboot we firmly believe that if your business is not in one of those 3 scenarios, there is no point in considering a native development.

Our favorite framework for building cross-platform apps is React Native for many reasons, some of which we have discussed in this post. In short, it allows us to apply our experience and knowledge in web development with React to create applications that work and look like native apps.

If you don't believe it, here are some examples of apps that we have developed with React Native.

Billbot: Billbot: subscription manager and recurring expenses (iOS | Android)

What is your opinion? Native or hybrid apps?

This post was originally published at Reboot Blog.

React Native Maps: How to install and use the map library on iOS and Android [2020]

Iván García — Thu, 12 Nov 2020 17:01:19 +0000

Maps have become one of the most popular interfaces for many of the applications that we have installed on our phones. Learning to work on maps, represent information appropriately and create a good navigation interface is becoming increasingly important.

In this post we will see how to integrate Google Maps into a React Native app using the react-native-maps library for iOS and Android. To develop an example as realistic as possible, we will recreate an Uber-style interface using a Bottom Sheet.

At the end of the post we will be able to develop an application like this one here.

Project creation

For this project we are going to use Expo to speed up the installation process and make it easy for anyone who wants to download the repository to test the application. If you still do not have expo installed you can follow the official installation guide.

The first thing we will do is create a blank project using the expo cli.

#We create a project named google-maps-example. We select the "blank" template
$ expo init google-maps-example

$ cd google-maps-example

$ expo start

Install react-native-maps library with Google Maps

Once the project is created, the next step is to add the react-native-map library using the command below.

expo install react-native-maps

If you are not using expo in your project, you can use this command

npm install react-native-maps --save-exact

o

yarn add react-native-maps -E

The difference between the first command and the second is that using the Expo cli we make sure to use the latest version of the library compatible with Expo.

It is worth mentioning that we can use the react-native-maps library with both Apple Maps and Google Maps. In this tutorial we will focus on using Google Maps as a map provider, but the steps to integrate Apple Maps are very similar.

Get the Google Maps API Key

In order to use Google Maps in our application, it is necessary to enable the iOS and Android SDK in a Google project with an active billing account in the Google Cloud Console and generate an API key to add it to our codebase.

Let's see step by step how to obtain the Google Maps API Key.

The first thing we will do is going to Google Cloud Console and create a new project that we will name google-maps-example-reboot.
Once we have created our project, we need to enable the Maps SDK for Android and the Maps SDK for iOS within the apis and services library.
Once the sdks are enabled, we need to create an API key. For this we go to the Control Panel → Create Credentials → API Key
Once the API key is created, it is highly recommended to limit it to the libraries that we want to use and to the applications that will have permission to use it using the application's fingerprint and the identifier bundle.

Now we have the API Key that we need to add to our application. Depending on whether we are using expo or a bare project, the way to do it will change.

Add API Key on Expo

On Expo we simply go to app.json and add this snippet:

// app.json

{
  "expo": {
    "name": "google-maps-example",
    "slug": "google-maps-example",
    "version": "1.0.0",
    "orientation": "portrait",
    "icon": "./src/assets/icon.png",
    "splash": {
      "image": "./src/assets/splash.png",
      "resizeMode": "contain",
      "backgroundColor": "#ffffff"
    },
    "updates": {
      "fallbackToCacheTimeout": 0
    },
    "assetBundlePatterns": [
      "**/*"
    ],
    "ios": {
      "supportsTablet": true,
      "config": {
          "googleMapsApiKey": "REPLACE_FOR_API_KEY"
      }
    },
    "android": {
      "adaptiveIcon": {
        "foregroundImage": "./src/assets/adaptive-icon.png",
        "backgroundColor": "#FFFFFF"
      },
      "config": {
        "googleMaps": {
          "apiKey": "REPLACE_FOR_API_KEY"
        }
      }
    },
    "web": {
      "favicon": "./src/assets/favicon.png"
    }
  }
}

Add API Key on Android

If it is a Bare Android project it will be necessary to add the API Key in google_maps_api.xml in the path android/app/src/main/res/values.

<resources>
  <string name="google_maps_key" templateMergeStrategy="preserve" translatable="false">(api key here)</string>
</resources>

Add API Key on iOS

On iOS you need to edit AppDelegate.m file to include the following snippet.

+ #import <GoogleMaps/GoogleMaps.h>
@implementation AppDelegate
...
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
+ [GMSServices provideAPIKey:@"_YOUR_API_KEY_"]; // add this line using the api key obtained from Google Console
...

  # React Native Maps dependencies
  rn_maps_path = '../node_modules/react-native-maps'
  pod 'react-native-google-maps', :path => rn_maps_path
  pod 'GoogleMaps'
  pod 'Google-Maps-iOS-Utils'

It is important to note that when using location permissions you must tell Apple why you need to access the user's location, otherwise Apple will reject your application when you upload it to the App Store. This can be done in the Info.plist file by editing the NSLocationWhenInUseUsageDescription field explaining clearly and concisely why you need to know the location.

Add and customize a map in React Native

Now that we have integrated the map library, we are going to start by creating a screen with the map visualization and customizing the style with the different options it provides. For this we are going to create a Map.js component like the following.

import React from 'react';
import { StyleSheet, View, Dimensions } from 'react-native';
import MapView, { PROVIDER_GOOGLE } from 'react-native-maps';
import { mapStyle } from './mapStyle';

export function MapScreen() {
  return (
    <View style={styles.container}>
      <MapView
        customMapStyle={mapStyle}
        provider={PROVIDER_GOOGLE}
        style={styles.mapStyle}
        initialRegion={{
          latitude: 41.3995345,
          longitude: 2.1909796,
          latitudeDelta: 0.003,
          longitudeDelta: 0.003,
        }}
        mapType="standard"
      ></MapView>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'black',
    alignItems: 'center',
    justifyContent: 'center',
  },
  mapStyle: {
    width: Dimensions.get('window').width,
    height: Dimensions.get('window').height,
  },
});

As we can see, the main component is MapView that has multiple props to customize its behavior. In this case, the most important ones are provider where we indicate that we want to use Google Maps, initialRegion which will be the initial location, mapType where we can define the type of map that is loaded and finally customMapStyle where we will set the custom style of the map we want to use.

If we look at the Google's official documentation we see that we can customize almost all the elements of the map. In this case we seek to make a minimalist interface so we will use the following styles.

//mapStyle.js
export const mapStyle = [
  {
    featureType: 'water',
    elementType: 'geometry',
    stylers: [
      {
        color: '#e9e9e9',
      },
      {
        lightness: 17,
      },
    ],
  },
  {
    featureType: 'landscape',
    elementType: 'geometry',
    stylers: [
      {
        color: '#f5f5f5',
      },
      {
        lightness: 20,
      },
    ],
  },
  {
    featureType: 'road.highway',
    elementType: 'geometry.fill',
    stylers: [
      {
        color: '#ffffff',
      },
      {
        lightness: 17,
      },
    ],
  },
  {
    featureType: 'road.highway',
    elementType: 'geometry.stroke',
    stylers: [
      {
        color: '#ffffff',
      },
      {
        lightness: 29,
      },
      {
        weight: 0.2,
      },
    ],
  },
  {
    featureType: 'road.arterial',
    elementType: 'geometry',
    stylers: [
      {
        color: '#ffffff',
      },
      {
        lightness: 18,
      },
    ],
  },
  {
    featureType: 'road.local',
    elementType: 'geometry',
    stylers: [
      {
        color: '#ffffff',
      },
      {
        lightness: 16,
      },
    ],
  },
  {
    featureType: 'poi',
    elementType: 'geometry',
    stylers: [
      {
        color: '#f5f5f5',
      },
      {
        lightness: 21,
      },
    ],
  },
  {
    featureType: 'poi.park',
    elementType: 'geometry',
    stylers: [
      {
        color: '#dedede',
      },
      {
        lightness: 21,
      },
    ],
  },
  {
    elementType: 'labels.text.stroke',
    stylers: [
      {
        visibility: 'on',
      },
      {
        color: '#ffffff',
      },
      {
        lightness: 16,
      },
    ],
  },
  {
    elementType: 'labels.text.fill',
    stylers: [
      {
        saturation: 36,
      },
      {
        color: '#333333',
      },
      {
        lightness: 40,
      },
    ],
  },
  {
    elementType: 'labels.icon',
    stylers: [
      {
        visibility: 'off',
      },
    ],
  },
  {
    featureType: 'transit',
    elementType: 'geometry',
    stylers: [
      {
        color: '#f2f2f2',
      },
      {
        lightness: 19,
      },
    ],
  },
  {
    featureType: 'administrative',
    elementType: 'geometry.fill',
    stylers: [
      {
        color: '#fefefe',
      },
      {
        lightness: 20,
      },
    ],
  },
  {
    featureType: 'administrative',
    elementType: 'geometry.stroke',
    stylers: [
      {
        color: '#fefefe',
      },
      {
        lightness: 17,
      },
      {
        weight: 1.2,
      },
    ],
  },
];

Customizing a Google map can be tedious, that's why there are websites like Snazzymaps that gather templates with different styles that we can directly copy their attributes and use as a template.

Add Markers to Google Maps in React Native

The next thing we will do is to add markers to our map. To do this we will create a constant MARKERS_DATA with the following structure.

import { default as Reboot } from '../assets/reboot.png';
import { default as Cravy } from '../assets/cravy.png';
import { default as Dribbble } from '../assets/dribbble.png';
import { default as Basecamp } from '../assets/basecamp.png';
import { default as Discord } from '../assets/discord.png';
import { default as OnePassword } from '../assets/onepassword.png';

export const MARKERS_DATA = [
  {
    id: '1',
    latitude: 41.3997999,
    longitude: 2.1909796,
    color: '#2F3136',
    name: 'Reboot Studio',
    direction: 'Carrer de Pujades, 100',
    img: Reboot,
  },
  {
    id: '2',
    latitude: 41.3995445,
    longitude: 2.1915268,
    color: '#A3EAD8',
    name: 'Cravy',
    direction: 'Carrer de Pujades, 101',
    img: Cravy,
  },
  {
    id: '3',
    latitude: 41.4009999,
    longitude: 2.1919999,
    color: '#E990BB',
    name: 'Dribbble',
    direction: 'Carrer de Pujades, 102',
    img: Dribbble,
  },
  {
    id: '4',
    latitude: 41.4001999,
    longitude: 2.1900096,
    color: '#EFD080',
    name: 'Basecamp',
    direction: 'Carrer de Pujades, 103',
    img: Basecamp,
  },
  {
    id: '5',
    latitude: 41.40009,
    longitude: 2.1909796,
    color: '#98AFE9',
    name: 'Discord',
    direction: 'Carrer de Pujades, 104',
    img: Discord,
  },
  {
    id: '6',
    latitude: 41.4009999,
    longitude: 2.1909796,
    color: '#4E87EB',
    name: '1 Password',
    direction: 'Carrer de Pujades, 105',
    img: OnePassword,
  },
];

Once we have our data ready, we can add it to the map by importing the library's Marker component within MapView. To do this we will use an Array.map function with the MARKERS_DATA that we have created.

//Map.js
import React from 'react';
import { StyleSheet, View, Dimensions } from 'react-native';
import MapView, { PROVIDER_GOOGLE, Marker } from 'react-native-maps';
import { mapStyle } from './mapStyle';
import { MARKERS_DATA } from '../../data';

export function MapScreen() {
  return (
    <View style={styles.container}>
      <MapView
        customMapStyle={mapStyle}
        provider={PROVIDER_GOOGLE}
        style={styles.mapStyle}
        initialRegion={{
          latitude: 41.3995345,
          longitude: 2.1909796,
          latitudeDelta: 0.003,
          longitudeDelta: 0.003,
        }}
        mapType="standard"
      >
        {MARKERS_DATA.map((marker) => (
          <Marker
            key={marker.id}
            coordinate={{
              latitude: marker.latitude,
              longitude: marker.longitude,
            }}
          ></Marker>
        ))}
      </MapView>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'black',
    alignItems: 'center',
    justifyContent: 'center',
  },
  mapStyle: {
    width: Dimensions.get('window').width,
    height: Dimensions.get('window').height,
  },
});

Voilà! We already have our markers on the map. But it still looks like any standard Google Maps map, so in the next step we're going to give it some personality by customizing the style of the markers.

Customize Google Maps Markers in React Native

The react-native-maps library includes several props to customize the style of the markers, but the best option if you want to create completely customized markers is to use the Marker component as a wrapper and create your own component with the style you want.

Following our minimalist interface we will add some circular markers and we will smoothly animate the size when the marker is selected.

We are going to create the CustomMarker component and a useMarkerAnimation hook to manage the interaction of the animation.

//Custom Marker
import React from 'react';
import { Marker } from 'react-native-maps';
import Animated from 'react-native-reanimated';
import { StyleSheet, View } from 'react-native';
import { useMarkerAnimation } from './useMarkerAnimation';

export function CustomMarker({
  id,
  selectedMarker,
  color,
  latitude,
  longitude,
}) {
  const scale = useMarkerAnimation({ id, selectedMarker });

  return (
    <Marker
      coordinate={{
        latitude: latitude,
        longitude: longitude,
      }}
    >
      <View style={styles.markerWrapper}>
        <Animated.View
          style={[
            styles.marker,
            {
              backgroundColor: color,
              transform: [{ scale: scale }],
            },
          ]}
        ></Animated.View>
      </View>
    </Marker>
  );
}

const styles = StyleSheet.create({
  markerWrapper: {
    height: 50,
    width: 50,
    alignItems: 'center',
    justifyContent: 'center',
  },
  marker: {
    height: 22,
    width: 22,
    borderRadius: 20,
    borderColor: 'white',
    borderWidth: 2,
  },
});

To manage the animations we have added the Reanimated and Redash libraries.

//useMarkerAnimation
import { useState, useEffect } from 'react';
import Animated from 'react-native-reanimated';
import { useTimingTransition } from 'react-native-redash';

export function useMarkerAnimation({ id, selectedMarker }) {
  const [active, setActive] = useState(0);

  useEffect(() => {
    const isActive = id === selectedMarker ? 1 : 0;
    setActive(isActive);
  }, [id, selectedMarker]);

  const transition = useTimingTransition(active, {
    duration: 200,
  });

  const scale = Animated.interpolate(transition, {
    inputRange: [0, 1],
    outputRange: [1, 1.5],
  });

  return scale;
}

Finally we replace the default Marker from the map screen with our custom marker we have just created.

//Map.js
import React from 'react';
import { StyleSheet, View, Dimensions } from 'react-native';
import MapView, { PROVIDER_GOOGLE } from 'react-native-maps';
import { CustomMarker } from '../../components';
import { MARKERS_DATA } from '../../data';
import { mapStyle } from './mapStyle';

export function MapScreen() {
  return (
    <View style={styles.container}>
      <MapView
        customMapStyle={mapStyle}
        provider={PROVIDER_GOOGLE}
        style={styles.mapStyle}
        initialRegion={{
          latitude: 41.3995345,
          longitude: 2.1909796,
          latitudeDelta: 0.003,
          longitudeDelta: 0.003,
        }}
        mapType="standard"
      >
        {MARKERS_DATA.map((marker) => (
          <CustomMarker
            key={marker.id}
            id={marker.id}
            selectedMarker={null}
            color={marker.color}
            latitude={marker.latitude}
            longitude={marker.longitude}
          ></CustomMarker>
        ))}
      </MapView>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'black',
    alignItems: 'center',
    justifyContent: 'center',
  },
  mapStyle: {
    width: Dimensions.get('window').width,
    height: Dimensions.get('window').height,
  },
});

All right! We already have our custom markers in our map app. But there is still a step left: we need to be able to navigate between the different markers. To do this we will create an interface based on a Bottom Sheet similar to the one found in applications such as Uber or Google Maps. This component will allow us to manage navigation between markers.

Manage map navigation

Let's see how we can navigate the map using both the animateCamera and the animateToRegion function. For this we need to create a map reference to be able to use it and call these functions. In our case we have created a hook to manage this logic.

//useMap.js
import { useState, useRef, useCallback } from 'react';

const DEVIATION = 0.0002;

export function useMap() {
  const mapRef = useRef(null);
  const [selectedMarker, setSelectedMarker] = useState(null);

  const handleNavigateToPoint = useCallback(
    (id, lat, long) => {
      if (mapRef) {
        mapRef.current.animateCamera(
          {
            center: {
              latitude: lat - DEVIATION,
              longitude: long,
            },
            zoom: 18.5,
          },
          500
        );
      }
      setSelectedMarker(id);
    },
    [mapRef, setSelectedMarker]
  );

  const handelResetInitialPosition = useCallback(() => {
    if (mapRef) {
      mapRef.current.animateToRegion(
        {
          latitude: 41.3995345,
          longitude: 2.1909796,
          latitudeDelta: 0.003,
          longitudeDelta: 0.003,
        },
        500
      );
      setSelectedMarker(null);
    }
  }, [mapRef, setSelectedMarker]);

  return {
    mapRef,
    selectedMarker,
    handleNavigateToPoint,
    handelResetInitialPosition,
  };
}

As we can see in the code above, the functions are quite simple. The animateCamera function receive as parameters: the center with the latitude and longitude, the Zoom and the time that the animation will take. In the case of animateToRegion function, the logic is very similar but instead of using the Type Camera it uses the Type Region.

In our case we have also added a setSelectedMarker to be able to enlarge the marker when the camera uses it as the center.

To use the hook we simply have to add it to our Map component. But before that we will create the component above the map to be able to use the hook functions.

We are going to create a Bottom Sheet component with the list of locations so when you click on one of these, the camera will move to that point and the selected marker will expand. For the component we have used the 'react-native-scroll-bottom-sheet' library that uses Reanimated to manage the component animations.

//BottomSheet.js
import React from 'react';
import { Dimensions, StyleSheet, View } from 'react-native';
import ScrollBottomSheet from 'react-native-scroll-bottom-sheet';
import { MARKERS_DATA } from '../../data';
import { ListItem } from './ListItem';

const windowHeight = Dimensions.get('window').height;

export function BottomSheet({ onPressElement }) {
  return (
    <ScrollBottomSheet
      componentType="FlatList"
      snapPoints={[100, '50%', windowHeight - 200]}
      initialSnapIndex={1}
      renderHandle={() => (
        <View style={styles.header}>
          <View style={styles.panelHandle} />
        </View>
      )}
      data={MARKERS_DATA}
      keyExtractor={(i) => i.id}
      renderItem={({ item }) => (
        <ListItem item={item} onPressElement={onPressElement} />
      )}
      contentContainerStyle={styles.contentContainerStyle}
    />
  );
}

const styles = StyleSheet.create({
  contentContainerStyle: {
    flex: 1,
    backgroundColor: 'white',
  },
  header: {
    alignItems: 'center',
    backgroundColor: 'white',
    paddingVertical: 20,
  },
  panelHandle: {
    width: 41,
    height: 4,
    backgroundColor: '#E1E1E1',
    borderRadius: 17,
  },
});

We will also add a top menu that will allow us to reset the state of our map.

//TopBar.js
import React from 'react';
import { StyleSheet, View } from 'react-native';
import { Avatar } from './Avatar';
import { RefreshButton } from './RefreshButton';

export function TopBar({ onPressElement }) {
  return (
    <View style={styles.container}>
      <Avatar />
      <RefreshButton onPressElement={onPressElement} />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    position: 'absolute',
    left: 0,
    top: 40,
    width: '100%',
    zIndex: 1,
    flexDirection: 'row',
    justifyContent: 'space-between',
    paddingHorizontal: 10,
  },
});

Finally the map component would look like this.

import React from 'react';
import { StyleSheet, View, Dimensions } from 'react-native';
import MapView, { PROVIDER_GOOGLE } from 'react-native-maps';
import { TopBar, BottomSheet, CustomMarker } from '../../components';
import { MARKERS_DATA } from '../../data';
import { useMap } from './useMap';
import { mapStyle } from './mapStyle';

export function MapScreen() {
  const {
    mapRef,
    selectedMarker,
    handleNavigateToPoint,
    handelResetInitialPosition,
  } = useMap();

  return (
    <View style={styles.container}>
      <TopBar onPressElement={handelResetInitialPosition} />
      <MapView
        ref={mapRef}
        customMapStyle={mapStyle}
        provider={PROVIDER_GOOGLE}
        style={styles.mapStyle}
        initialRegion={{
          latitude: 41.3995345,
          longitude: 2.1909796,
          latitudeDelta: 0.003,
          longitudeDelta: 0.003,
        }}
        mapType="standard"
      >
        {MARKERS_DATA.map((marker) => (
          <CustomMarker
            key={marker.id}
            id={marker.id}
            selectedMarker={selectedMarker}
            color={marker.color}
            latitude={marker.latitude}
            longitude={marker.longitude}
          ></CustomMarker>
        ))}
      </MapView>
      <BottomSheet onPressElement={handleNavigateToPoint} />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'black',
    alignItems: 'center',
    justifyContent: 'center',
  },
  mapStyle: {
    width: Dimensions.get('window').width,
    height: Dimensions.get('window').height,
  },
});

We have managed to build a maps application with a very simple interface that allows us to manage navigation between the different points of interest in a very intuitive way. Much more complex products can be built on top of this, but it is a good starting point if you are developing a map app in React Native in 2020.

The complete project is available on GitHub so that you can download and work on it.

This post was originally published at Reboot Blog.