Here at SmartLogic, we’ve been using React Native since it first launched in 2015, and we still love its reusable components and cross-platform ease. We especially love how pure components and rapid prototyping allow us to make big leaps forward in the beginning of projects, especially when we’re collaborating with another team who will be providing pieces of the application later in the development process.
Design basic components to get the feedback cycle started early
We often work with other dev teams on smaller projects, when they’re looking to add on an extra feature or spin up a new project outside the scope of their team. Collaborating with other developers is fun and just a different ball game. It is sometimes the case that we are working on the same project in tandem, which can mean that some details and endpoints might not be in place before kickoff. This is where having React is so nice.
Even without a finalized back end, we can begin framing out the app with the major UI elements and developing the reusable components which will serve as the building blocks for much of the project, like textboxes, select options, and modals. This allows us to take a significant and very visual first bite, and allows us to start our iterative feedback process early on. Frequent client communication ensures everyone is in step, and having something clients can look at for feedback early and often is what we aim for. The sooner you have deliverables to play with, the more you can refine as you go; we find it helps to illuminate the pieces still to come, if something has been overlooked or can be tweaked for a better experience.
Know what not to build and what to watch for changes
Identifying immediately actionable areas and places where we’ll want to pace ourselves is crucial. It’s easy to want to tackle a major section that just doesn’t have enough back end definition yet, only to get stuck changing and reworking things down the line. Data structures, primitive types, key names and payloads may all be subject to change. Focusing on components with more existing definition and making a clear point to not dig in to areas that don’t yet have enough detail established will help you avoid rework. Remember that applications are always living, iterative projects.
Use real data when you have it, and fake it when you don’t
In cases where data isn’t coming through to the front end yet, we try to seed data as much as possible so we can really get components working and displaying the way they need to. In a pinch we might fake some data locally in the component just to give us a head start, the goal being to avoid or at least diminish bottlenecks and rework. The catch however, is that as the project moves along, the API and data structures may be changing.
In a recent project, for example, we had seed data that should have been a perfect mirror of the API data we would eventually be receiving, but it turned out that there were type mismatches between the mock data and the eventual API. On another project, the data ordering was unexpectedly modified based on user interaction. Mapping too tightly to data structures that are not yet fully defined ends up creating more work down the road. We find in these cases it’s better to leave a comment and just drop in some placeholder data to allow you to work on visual styling while holding off on building functions until the actual data structure becomes clear.
Hit the ground running with React
We love building with React components because even in circumstances where we can’t go about building an app A to Z, we can still hit the ground running by constructing much of the infrastructure and styling. This helps us to quickly jump into our iterative comfort zone, making the app come to life and getting us immediate feedback as we move along. The only catch is knowing where to slow down, switch gears and not overdevelop where things will be changing. Thanks to the reusable component-driven nature of React, we’re working more efficiently with less code, a cross-platform mobile advantage, and flexibility that helps prevent us from stalling at underdeveloped points in projects.
Header photo by Markus Spiske on Unsplash
