Latest Posts

Technology

8/22/18

Bringing Rails Convention to the Wild West of JS

Necessity is the mother of invention — but Rails is the mother of convention. And sometimes, what you really need is some structure.

Here at 20spokes, we have branched into mobile in a big way, using React Native with Rails APIs. As a consultancy, we have the unique perspective of building projects from scratch often, and we kept coming back to folder structure. Namely, how on earth does anyone find anything in a React Native (or React.js) app as it grows?

Most of the React tutorials we saw out there had three main folders for their files: elements, modules, and components. (Redux projects will sometimes expand that to include an actions folder.) But try getting someone to actually define what an element is, versus a module, versus a component, and the argument quickly becomes circular. Elements are reusable, they say. Well, so are modules. Modules are bigger, though. Sort of.

So we decided to write our own rulebook. Trash it if you like, but it’s worked pretty well for us so far, and going back to maintain projects we built before we established this style? The difference is mind-boggling.


    |_ __tests__
      |_ ...mirrors the src folder
    |_ android
    |_ assets
    |_ ios
    |_ src
      |_ actions
      |_ contexts
        |_ Profile
          |_ modules
            |_ AvatarUploader.js
          |_ views
            |_ EditProfileView.js
            |_ PublicProfileView.js
          ProfileStyles.js
      |_ elements
        |_ Buttons
          |_ ButtonPrimary.js
          |_ ButtonSecondary.js
      |_ helpers
      |_ layouts
      |_ navigators
      |_ utils
    App.js
    index.js

Along with this folder structure, we’ve employed babel-plugin-module-resolver to help with the dreaded strings of ../../../../ before import statements. That way, every time we need a common element in a view within the contexts folder, the import path can be as simple as elements/Buttons/ButtonPrimary.js. Learn more about that plugin here — it’s been key to our success with this structure.

Putting it into contexts

If you’re building any kind of mildly robust mobile application that makes requests to an API, you probably have several "flows" through the app. Settings. Login. Feed. Profile. Onboarding. Any "section" of the app that you’ve probably already chunked out as a feature set is probably also a context. We decided to create a folder for each of these contexts, with all the views in that context along with all of the modules/elements that are particular to that context. [1]

For example, a public profile view, an editable profile view, and an avatar uploading module would all be in a Profile context folder. If an element is reusable outside of that component, stick it in the elements folder instead. The contexts folder was the real heavy-hitter in our redesign. You’re welcome.

Let me lay it out for you

Most of the apps we create have custom navigation bars/drawers or SafeArea wrappers that need to go on every page. We usually call this a ViewWrap.js or TopNav.js, whatever the use case is. Sometimes different kinds of views have different view wraps. The layouts folder is for these — just like in Rails.

Check the GPS

The navigators folder is a handy place for all your navigation-related files.

If you’re familiar with navigation libraries for react like React Navigation, you know that each app "flow" needs a navigator file or something like it. We used to keep these in the junk pile, AKA the top level of the folder structure along with App.js and index.js. But for complex apps with lots of form flows, or different user journeys, having a navigators folder — with subfolders like Admin or Onboarding or other, more specific navigational needs — makes it a lot easier to grok the app’s navigational complexities.

Going off the Rails

As a software consultancy, we have a particular interest in making sure that our code is easy to read and maintain by another team sometime down the line. But let’s be honest — we’ve all read a codebase that we wish had been written with future developers in mind.

Going back to old projects, ones built before we adopted this new folder structure, isn’t a total nightmare (we have always been pretty good at this readability stuff, after all). But it truly is amazing how much of a difference the new structure has made. No longer do I have to wonder which Events folder is going to have EventCard.js in it — src/elements/EventCard.js or src/modules/EventCard.js? There’s only one Events folder, src/contexts/Events. Something reusable like a card will maybe be another folder deep, in a modules folder particular to events. But that’s it. No more digging!

Even if you decide not to implement our folder structure for your next React or React Native project, what I hope you’ll take away from this success story is that it’s invaluable to consider lessons you’ve learned from other frameworks. What makes Rails infinitely easy to jump into and know where to look for things is totally doable in React. So get after it!

[1] We did not know that React 16.4.2 was about to come out with this Context thing. Sorry for any confusion. Call the contexts folder whatever you want?

Technology

7/6/18

Using Active Storage with Active Model Serializers

Attachment is the root of all suffering. If you’re a web developer, attachments are the root of all suffering.

Paperclip, a longtime go-to gem for managing file attachments, has been deprecated in favor of Active Storage, which is now officially part of Ruby on Rails as of version 5.2. So for a recent greenfield app, I took the dive into Active Storage.

Switching out dependable gems for new ones can be anxiety-inducing, but that’s web developer life. While Active Storage ended up being a breath of fresh air for many reasons, it came with a few of it’s own gotchas, particularly when dealing with querying data.

Active Storage and N+1 queries

Let’s say a user has one avatar. While Paperclip would add a few columns to your users table to store the avatar’s file data, file type, etc., Active Storage will create new tables that are solely responsible for keeping track of asset data and associating this data to your records.

These tables are called blobs and attachments. Blobs represent the actual metadata of the files, whereas Attachments are what join blobs (file data) to your application’s records (users). For every file you upload, a blob is created and associated to your record through an attachment.

These relationships are created when you attach a file through Active Storage using the has_one_attached shorthand:

class User < ApplicationRecord  
  has_one_attached :avatar

It’s important to understand these relationships between blobs and attachments when dealing with record queries that may have attachments.

For has_one_attached relationships, you can avoid N+1 queries by adding the with_attached_X method that Active Storage generates for you based on your attachment name:

User.with_attached_avatar.where(active: true)  

This is basically saying:

User.includes(avatar_attachment: :blob).where(active: true)  

I had to take special care of these relationships when using Active Model Serializers. Normally, when dealing with child records in a serializer, you can define a relationship using has_one or has_many:

class GameSerializer < ActiveModel::Serializer

  attributes :title

  has_many :users

If my User Serializer is using the avatar in any way, this would create an N+1 scenario:

class UserSerializer < ActiveModel::Serializer

  attributes :avatar_url

  def avatar_url
    ...object.avatar_url...

In order to avoid N+1 queries here, I had to ditch the built-in has_many and create a custom users method for the Game Serializer:

class GameSerializer < ActiveModel::Serializer

  attributes :title, :users

  def users
    User.with_attached_avatar.where(game_id: object.id)

Finding the right asset URL for serialization

When passing image urls through serializers, I had to search through some Active Storage Github issues and documentation to find the right url to use.

Creating images of smaller sizes is common for real-life use of your assets. Active Storage calls these variants. You’ll most likely use variants rather than the original asset in serializers.

If you want a url of the asset variant, include the Rails.application.routes.url_helpers module in your serializer, then use rails_representation_url in your url method:

class UserSerializer < ActiveModel::Serializer  
  include Rails.application.routes.url_helpers

  attributes :avatar_url

  def avatar_url
    variant = object.avatar.variant(resize: "100x100")
    return rails_representation_url(variant, only_path: true)
  end

If you want to use the original asset, use rails_blob_path instead:

return rails_blob_path(object.avatar, only_path: true)  

So there’s a little extra work when serialization is concerned, but overall I really enjoyed working with Active Storage and appreciate what a great thing this is for the Rails community.

Technology

7/6/18

React and its Less-Cool Cousin, Semantic HTML

One of the best and most meaningful features of HTML5 is its introduction of more “semantic” tags, or tags that help define the structure of a webpage. Tags like section, article, footer, nav, and aside are highly useful for improving the accessibility of a website for visually impaired users. They provide valuable information about your site to any screen readers that are processing it, allowing for easier browsing and less time wasted with repeated or irrelevant information. Semantic tags improve your site's SEO rankings for the same reason — they help search engines understand what your site is about. And on a more basic level, these tags make it easier for developers to understand what role each element plays on a particular page, increasing maintainability.

So where does semantic HTML fit into the React.js framework?

React requires that any render function returns a single parent element that contains the rest of the content. Depending on the complexity of your UI, this rule can result in an bulky Matryoshka doll of divs, divs, and more divs. The benefits of semantic HTML can get muddied by just how easy it is to stick another handy, neutral div in your component tree, especially when (out of habit) you start using divs in place of more semantically useful tags, like button or nav.

Enter React v16.2.0, released in November 2017, which introduced an awesome new feature called Fragments:

"Fragments look like empty JSX tags. They let you group a list of children without adding extra nodes to the DOM."

With this addition to the React framework, there’s no reason to bulk up the DOM with more div tags. There’s a handier, even more neutral tag in town that does exactly what we need.

render() {  
    return (
        <>
            <h1>Content title</h1>
            <p>Sample content</p>
        </>
    )
}

Fragments are a way not only to streamline your webpage, but also to get out of the habit of using a div when another, more specific tag would make sense. Let’s make the internet a more accessible place by remembering that for some consumers, semantic HTML isn’t just “nice to have.” It’s essential for navigating your UI.

And hey — no more sifting through divs to debug your front end, am I right?

See More

What People Are Reading

Operations

8/29/16

Watch us eat our own dog food

20spokes is trying a new diet, so to speak. If you’re unfamiliar with the phrase “eating your own dog food,” it’s a common expression in the software world referring to a developer’s practice of using their own products. It’s said to have originated from 1970s television advertisements for Alpo dog food, where the owner of the company would make a point of feeding Alpo to his own dogs. So in its broader interpretation, “practice what you preach” would be an appropriate alternative. Either way, if we can help others build great products, we want to show that we can build our own great products as well.

It’s something we’ve thought about for a while, and now we’re finally taking the steps to make it happen. Client work will still always be our primary focus, but we have the team, the experience, and the aspirations; why wouldn't we work on our own ideas too? Like our clients, though, we don't want to jump into these ventures haphazardly only to end up with a well built app that nobody else wants. So we're putting these ideas through the same process of discovery, validation, and planning that we would with anyone who came into our office. In a way, by becoming clients of our own process, we’re getting our first helping of dog food!

Over the last week or so, we’ve adopted the mindset of a founder with a vision, and taken one of our ideas through the first steps of conception. Working through this process as the “founder” has already given us some great new insight, and we're excited to share this journey with you. So stay tuned for the next several weeks as we document all the steps we take and lessons we learn along the way; we're going to find out just how good our dog food tastes.

Trying to get your own product idea to market? Contact us to learn more about our process and how we can help.

Operations

8/1/16

Good Founders Make Good Clients - 5 Traits We Look For

“Ideas are easy. Implementation is hard.” – Guy Kawasaki

As a development agency that primarily works with early stage startups, we hear all kinds of business ideas. You could even say that we're in the business of building business ideas; but only one's we believe will succeed, and not on our own. We know that, without a good founder to drive implementation, even the best ideas will surely fail. In fact, most give up at the first sign of real challenge, and their ideas never see the light of day. So while we spend time evaluating the viability of the idea, we must also consider if the founder has what it takes. Here are the 5 traits we look for:

1. Tenacious belief. Some traits can be learned or honed; this is not one of them. Startups are inherently difficult, demanding, and full of unknowns and disappointment. To make it through, a founder needs confidence, determination, passion, and the like - things you can't have without first believing. We're not talking about simply believing you have a good idea. We're also not talking about blind belief to the point of delusion. This is believing strongly enough in your vision that, despite the uncertainties and inevitable struggles in your path, you will do whatever it takes to see it through.

2. Domain expertise. Serious founders need to understand their market as much as possible. Ideally, you can directly relate to the problem you're trying to solve - or - you have extensive experience that gives you insight on your target market. Even then, the best founders do everything they can to consistently learn and absorb new information.

3. Communication. The greatest entrepreneurs are masters of communication. Not all start out that way, but its something to be conscious of and constantly improve. A good founder has the ability to communicate clearly, confidently, and candidly. They can clearly explain their thoughts and ideas. They use confidence to sell themselves and their vision, as well as to lead others. They can candidly express their feelings, while maintaining control of their emotions.

4. Head in the clouds, feet on the ground. Growing a startup requires constant innovation. A good founder has vision; they dream big and consistently ask themselves, "what's next?" However, that vision will never materialize unless a founder can execute in the present. A good founder can keep their eyes to the future while practicing self awareness, focus, patience, and responsible decision making.

5. Flexibility. The survival of a business, like in nature, depends on its ability to adapt. No matter how much a founder plans, new information will arise and circumstances will change; a good founder is prepared and willing to respond. Some changes will inevitably result in failures. A founder must have the resilience to pick themselves up, learn from the failures, and push on.

6. Enjoys the ride. I know I said 5 traits, but this one's pretty important too. Yes, starting a business is difficult, risky, blah blah blah...but what's the point if you can't enjoy it? Having fun will not only make your life (feel) easier; attracting advocates, customers, employees, and investors will be easier as well.

Now these aren't the ONLY things a founder needs to build a successful business, nor do they guarantee success, but we'd bet on you. So if you have a great idea and "what it takes" (see above), we should meet.

Client Work

PupJoy

We automated PupJoy’s operation and gave back hundreds of man-hours (so we could all spend more time with our best friends).

Rhabit

Want to watch a video of player mechanics while streaming a video chat with your tennis coach? We made it possible with Rhabbit.

Enough about us. Let's talk about you.

Get in touch with us