Forem: JP Erasmus

The 80/20 of Flexbox

JP Erasmus — Sun, 20 Oct 2019 20:16:06 +0000

This article aims to explain the 20% of flexbox that you’ll use 80% of the time.

What is Flexbox?

Flexbox is a way to describe how elements should be displayed inside another element. The outer element is called the flexbox container, and the inner elements are known as flexbox items.

How does it work?

A flexbox container is created by adding a display CSS property with a value of flex on it. Any direct child elements inside this container inherently become flex items. A flex item itself could also be a flex container for its child elements, but consider that as a completely isolated flexbox relationship. A flexbox relationship is always a single level deep between a parent element and one or more children.

After declaring your flexbox container, all flex items will by default be placed horizontally next to one another, starting at the left and stretching to the height of the container.

The default Flexbox layout

Flexbox Container properties

To dictate whether flex items should be laid out horizontally or vertically, you set the flex-direction property to either row (horizontal default) or column (vertical). There are also reverse "row" and "column" options available that will lay items out horizontally, from right to left (row-reverse) or vertically from bottom to top (column-reverse), assuming you use a horizontal left to right writing mode.

Assuming you use the default flex-direction: row declaration. To specify how items should be placed on the horizontal axis (known as the main axis), think about the justification options you normally have in a rich text editor, i.e. aligned left, aligned right or centered. In flexbox, you use the justify-content property on the container to do the same. The default is justify-content: flex-start that aligns the items at the start of your main axis. Other possible values are flex-end, your best friend center, and lesser-used space-between, space-around and space-evenly.

Justify Content Examples

To specify how flex items should be placed vertically in the container, on what is known as the cross axis, you use the align-items property. The available values are very similar to what you get for justify-content, with a few exceptions: flex-start, flex-end, center, stretch and baseline. By default flex items will stretch the full height of the container. To place items at the top or bottom along the cross axis, use flex-start or flex-end respectively. Traditionally, it has been quite hard to vertically centre items using only CSS, but with flexbox, you set align-items: center and call it a day. The baseline option is worth knowing about, but you'll use less often. If you have neighbouring flex items containing different sized text and you want to align them based on the bottom of the text, use baseline.

Align Items Examples

Have you noticed that we’ve already catered for most layout requirements, and so far we didn’t specify a single CSS property on any flex item? Everything has been on the flex container. Amazing.

With that said, if you need to align items individually, you can set the align-self property on an item. It takes all the available values that the container's align-items supports.

It is worth mentioning again that all the examples so far assume a left-to-right writing mode and the default horizontal row flex-direction. When either of these change, the concepts remain the same, only your perspective changes. What I mean is that in a right-to-left writing mode using flex-direction: column-reverse, items will be justified along the main axis from bottom to top, but now aligned along the cross axis from right to left.

What I’ve found is that it is easier to grasp the fundamentals first using the standard flex-direction: row. After that, you can swap the flexbox axes around in your mind to visualize how reversed columns would work.

The last flexbox container property worth talking about is flex-wrap. By default flex items will not wrap to a new row when they run out of horizontal space. They rather get very cosy and squash together as far as possible until the CSS layout engine decides that's enough.

To tell these items rather wrap to a new row, set flex-wrap: wrap. As I mentioned, the default is flex-wrap: nowrap.

Flex Wrap Examples

That wraps up all the container properties that we’re going to talk about. The rest of the properties are all set for individual flex items.

Flexbox Item Properties

The cosy behaviour of flex items to squash together can be overridden with the flex-shrink property. This property dictates in what proportion an item should shrink inside the container when space becomes scarce. The default is flex-shrink: 1, which means all items shrink equally. If one of the items is set to flex-shrink: 2 while the rest keep a value of 1, this item will shrink twice as fast. It is important to note that the value is a unitless value that represents the shrinkage proportion and not something like 10px or 50%.

Flex Shrink Example

In contrast to flex items’ cosy shrink behaviour, they tend to be slightly shy by nature and will not “occupy all spaces” if any free space is available. In more official terms, all flex items have a flex-grow value of 0 set, which restricts it from growing. Just as with flex-shrink, flex-grow is a unitless value that dictates in which proportion an item should grow within a container if any free space is available. It is important to note that if you have two flex items, one with a flex-grow value of 1 and the other of 2, that does not mean the one item will be twice as big as the other. It means, from all the available space (if any), the one will receive two portions and the other, one portion.

Flex Grow Example

The final flex item property we’ll cover is flex-basis. You can think of flex-basis as the width of an item along the main axis. This property needs to be set with any of the standard CSS units, for example px, rem, %, vw, etc. The default is flex-basis: auto which means the item takes the width of the content it contains, similar to a display: inline-block element.

A caveat to this rule is when a width is specified, in which case the width would trump the default flex-basis: auto. Another interesting thing to be aware of is that if you have a min-width specified along with a non-default flex-basis, the min-width will always take precedence.

Flex Basis Example

Of course, there is a lot more to flexbox, like shorthand syntax for some of the properties we looked at. Feel free to dig deeper once you’re comfortable with these.

Originally published at https://jperasmus.me.

Quality-first UI Development

JP Erasmus — Tue, 23 Jul 2019 20:23:11 +0000

Photo by Kyran Aldworth on Unsplash

In the same spirit as mobile-first and offline-first, I want to write about quality-first.

It merely means: start with quality in mind and don’t make it an afterthought.

If we say we are professional developers, the quality of the systems we produce is our responsibility.

Does this apply to you? Ask yourself these two questions:

Does the majority of the work you do revolve around software development? Not coding, but development
Are you paid to do it?

If you answered “yes” to both these questions, congratulations, you are a professional! 🎉

You can let the imposter syndrome go, you made it!

No one knows everything. Not even close. We’re all still on the journey to master this craft. Everyone started with zero knowledge, zero experience.

Now that we’ve established that quality is our responsibility let’s talk about it.

We’re going to look at quality from two perspectives: UX & DX (user experience and developer experience)

Instead of getting hung up about the correct definitions here, in light of this post, they mean quality from the perspective of the end-user and the developer.

I would argue that good DX goes a long way in helping to produce good UX. If you don’t agree, let me know on Twitter.

UX

We all agree UX is essential. If users have a terrible experience, they’ll leave, and without users, what’s the point in what we build?

To produce a good user experience, we need to understand our users and how they use our products.

Some questions we need to ask about our users:

Who are they?
From where are they?
Which browsers do they use?
Do they have any disabilities?
Are they native English speakers?
What type of devices are they using?
How stable are their internet connections?
What time of day do they typically use the product?

You get the point. Most of these you probably already think about, but if you’re not, now is an ideal time to start exercising those empathy muscles.

DX

Developer Experience is focusing on the developers’ quality of life during the development process. A lot of DX comes down to tooling. These tools include the frameworks we choose to use, our IDE’s, browser developer tools, plugins, CI/CD processes and more.

If you are a team lead, it is your responsibility to set your team up for a win. Make it hard for teammates to produce poor quality by adequately setting up build processes, linting, tests and deployments.

Accessibility

Accessibility is sometimes a weird subject, and people get very vocal and defensive about it. It doesn’t need to be that way.

When you hear accessibility, most people think about blind people, but it is about a lot more. It is about real people with real lives and how we, as developers cater to these humans, our users. It is about the web being accessible to as many people as possible. No other platform can do that.

According to the World Bank Group, 1 billion people, or 15% of the world’s population, experiences some form of disability, with more than 100 million of them with a severe disability.

To put that in perspective: IE11 currently has 2.75% global usage, and we’re building websites that work in it. If we care about this small percentage, why would we not cater to the 15% of people with disabilities? I’m not saying that the full 15% of people with disabilities use the web, but the good news is that these users aren’t using IE, that’s for sure. 🤗

We should not charge extra for accessibility. It is part of the quality that we, as professionals, should deliver.

Some things to consider:

Can your app be navigated with only a keyboard?
Is your app friendly to screen readers used by people with sight impairments?
Does your app assume users can distinguish options solely based on colour?
Is there enough contrast between your UI elements (text vs background colours, etc.)?
Does the user prefer reduced motion?
Do all your videos provide subtitles?

What can we do?

Set up tools like ESlint that make us aware of obvious accessibility issues in our code
Learn proper HTML semantics
Learn about ARIA
Use browser and CLI tools to test accessibility issues
Play with a screen reader
Test navigating your app using only your keyboard
Speak up when you notice UX that could be better. Don’t be a developer that only do what is given to you. Use your beautiful brain; you’re a professional, remember.

Security

We’re not all working for the CIA, but there are some simple principles we can put in place to vastly improve security in our apps.

Things to consider

Are all your pages served over HTTPS? There isn’t a good reason for your app not to use it anymore. Most hosting providers provide an SSL certificate for free. More than that, many web API’s and features like Service Workers only work for sites served over HTTPS.
Use HTTP headers like HSTS and CSP to restrict your site from ever running over plain HTTP or loading any other resources on your page. With something as basic as this, you can almost eliminate most technical security issues.
Is your app taking any user input? If so, make sure you sanitize everything. A good example is when writing HTML to the DOM using innerHTML. If the HTML string you're writing is coming from a user, they can effortlessly inject a script into your app. Expect the worst. It is suitable for a developer to be slightly cynical.
Most of the time, the most significant gap in our security plans, is us, the humans involved. A solid philosophy to follow when it comes to security is the “principle of least privilege”. It simply means to provide the minimum permissions needed to accomplish a task and nothing more. For instance, if a user should only be able to add a new entry, don’t give them delete permissions. At startups, when iterating quickly, this can be unnecessary red tape for your internal systems, but think about it and make a decision that suits your team the best.

Performance

Performance is probably one of the most critical aspects of quality software that we can look at, both from a user’s and a developer’s point of view. Numerous studies have reported the financial gains, or losses companies have when seconds are shaven off from their app load times. We should, therefore, optimize for performance as much as we can.

We can also look at performance from the point of delivery: how long development of a feature takes. In other words, efficiency. Feature development is an area where faster isn’t always better for quality. On the other hand, slower also does not necessarily mean better quality. Tools can help us.

Let’s face it; we are not good at repetitive tasks. When you’re moving fast, you can not possibly remember to check everything. Set up your tools beforehand to catch apparent mistakes, and when things slip through the cracks, update your tools for the next time. I use the term “tools” very loosely here. These tools can be code linters, unit tests, spell checkers, release checklists, etc.

I’m personally not someone that would argue that a Computer Science degree is necessary to be a top-class developer. One thing I would say is that everyone should understand Big-O notation. I’m not talking about heavy computer science theory, but as a way to think about the code you just wrote and how well it performs. Understand the difference between time complexity versus space complexity. A function can have O(1) time complexity, but be so extremely heavy in terms of space complexity that your user’s device runs out of memory. An O(1) function is useless in that scenario. With this said, Big-O is something to be aware of — if you’re thinking about it, you are already winning.

Communication

I’m not going to say much about this, because we hear it all the time, communication is essential in most areas of our lives. Instead of quoting another cliché, let’s talk about one or 2 places where communication is important in our day to day jobs as developers:

Code Reviews

Few communication tools make such a big difference, in the quality that we produce, as code reviews. I want to encourage you to note how you communicate on code reviews. As the person creating a pull request: are you clear about the intent of your code change? Use commit messages, PR descriptions, or before and after screenshots. These things go a long way in giving your reviewers some much-needed context.

From a reviewers point of view, are you “listening” (paying attention) to the proposed code change? When you give feedback, are you merely nitpicking at a preferred code style or are you aiming to add value? A good thing to keep in mind is the concept of “ Radical Candor”. It boils down to this: speak plainly but from a place of caring about the person and the product. It is healthy to disagree with and question a code implementation, but it is not cool doing that in a mean and condescending way. Luckily everyone at Responsive is generally pretty friendly, so this is rarely an issue. 🙂

Task Loggers

When you write a task description or comment, be a human, think about the person that will be reading it. If that person is not another developer, don’t use all your tech jargon. If you’re writing things and the other person doesn’t understand you, are you communicating?

Always aim for simplicity and clarity.

Testing

I’ll be first to admit that testing is not always the most fun thing to do. No one makes hacker movies about testing; it just isn’t that sexy.

There are probably as many opinions about the different types of testing as there are developers with right hands, so here’s mine for UI testing:

Not all types of testing are useful
TDD does not work well for pure presentational components. It is much easier to add tests after the fact for this.
Your tests should reflect how a user would interact with the UI as closely as possible — tweet inspiration
Sometimes tests are not worth the time investment
Sometimes tests will save your bacon
Unit tests are beneficial for developers and not for stakeholders — stakeholders should not be concerned with code coverage. Developers should write enough unit tests for them to feel confident, rolling out quality code.
Unit tests work best for pure logic-based functions
There is a much higher ROI for end-to-end and integration tests than for unit tests. It is better to spend time setting up automated tests to cover the critical journeys in your application than to chase 100% test coverage for your unit tests.
Tests should run as part of your CI process so that adding code to your main branches requires passing tests.
Tests should be first-class code in your app and updated alongside the rest of your app code.

We now know that we want to put quality first, but how do we practically do that? We touched on many useful tools, but I want to take the rest of this post to chat about one particular tool that puts quality front and centre: Cypress.io

Cypress

Cypress.io is an open-source, front-end testing tool, built for the modern web.

Why Cypress?

Cypress is most often compared to Selenium, but it is fundamentally different based on its architecture. Some of you, I know, have experience with tools like Chimp and Protractor that uses Selenium under the hood. Chimp uses WebDriver, which is Selenium.

I’ll admit that writing BDD tests on CHEP was probably my least favourite part while I was on the project. Don’t get me wrong, the idea of automated UI tests excited me just as much as any other dev-nerd, but I sat most of the time debugging flakey tests. It just never seemed to do what I wanted. This led to zero confidence in the tool. What is the point in doing it if it doesn’t give us confidence in the app’s quality?

Where Selenium and other similar tools interact with your application by sending commands from outside the browser, Cypress takes an entirely different approach and works directly within your browser.

Why is this great?

Cypress can do things that Selenium simply can’t do. Things like mocking out network requests, setting items in local storage, and directly interacting with your app’s state. Selenium can only make educated guesses about your app’s state; Cypress knows intricately what is going on in your app.

No more flake! No more pain!

Getting started

Getting up and running with Cypress is extremely easy, so I won’t be covering it in this post. Install it from NPM and then to run it. Their documentation is excellent — I encourage you to take a look.

The first time you run the cypress open command, it will install Cypress itself and then open the interface. This UI is an Electron app, and like everything else about Cypress, it is 100% written in JavaScript.

You can run Cypress with the UI Electron app or headless using the cypress run command. The headless option is useful for integrating Cypress into your CI pipeline.

Killer Features

Time travel

Realtime reloads

Debuggability

Since Cypress runs inside the same browser context as your app, you can easily debug it with familiar tools. Drop a debugger straight in the code or console.log to your heart's content. Should I mention that since Selenium uses the same debug protocol as the browser developer tools, it is impossible to open the dev tools while it is running? It is crazy how we have been fine with this for so long.

On top of that, Cypress gives you meaningful error messages.

Automatic waiting
Spies, stubs, and clocks
Network traffic control
Consistent results
Screenshots and videos

I’ve been relatively harsh towards Selenium up until now. It is only fair to say that Selenium is a decent product that served its time well. In the past, before the era of JavaScript frameworks, web apps were a lot simpler. Every user action almost always resulted in a page refresh, which means there was little to no state that needed to be handled by the client. Today’s apps are incredibly complex, and we need new tools to help us make sense of it all. Cypress is such a tool.

Some links:

Originally published at https://jperasmus.me.

The Web Developer’s Oath

JP Erasmus — Tue, 18 Sep 2018 21:32:26 +0000

Photo by rawpixel on Unsplash

For the longest time within the medical profession, new physicians have taken the Hippocratic Oath (or some variation of it) in which they swear to uphold a certain ethical standard. With the great responsibility resting on these individuals, it makes total sense to do this.

As developers, our actions can sometimes have massive impact on other people’s lives, but yet ethics is not something discussed much in software development circles.

What follows is an adaptation of the Hippocratic Oath, but for web developers:

I swear to fulfill, to the best of my ability and judgment, this covenant:

I will respect the hard-won scientific gains of those developer giants whose blogs I’ve read, and gladly share such knowledge as is mine with those newbies who are to follow.

I will apply, for the benefit of all project stakeholders, all linting rules that are required, avoiding those twin traps of over-engineering and premature optimizations.

I will remember that there is art to web development as well as science, and that warmth, sympathy, and continuous learning may outweigh the developer’s current framework preference or build tools.

I will not be ashamed to say “I know not,” nor will I fail to create a Stack Overflow question when the skills of another are needed for a project’s successful outcome.

I will respect the privacy settings of my end users’ browsers, for their logins to my app are not disclosed to me to insecurely store in plain text. Most especially must I tread with care in matters of code reviews. If it is given me to approve a PR, all thanks. But it may also be within my power to decline the PR; this awesome responsibility must be faced with great humbleness and awareness of my own code under review. Above all, I must encourage diversity.

I will remember that I do not style a button, implement an algorithm, but provide a digital experience, whose outcome may affect my users’ family and mental stability. My responsibility includes these related problems, if I am to care adequately for my craft.

I will prevent bugs whenever I can, for continuous improvement is preferable to rewrites.

I will remember that I remain a member of society, with special obligations to all my fellow nerds, those sound of mind and body as well as those suffering from imposter syndrome.

If I do not violate this oath, may I enjoy fast internet and cross-browser consistency, respected while I code and remembered with affection when I become a project manager. May I always develop so as to preserve my end user’s valuable mobile data and may I long experience the joy of coding apps that are accessible as the open web ought to be.

In all seriousness, as a developer, next time you implement a new feature, create a GitHub issue, write a blog post or deliver a meetup talk, consider the impact of your actions on other people. Behind the code, there is a person.

How to set Firebase security rules for your Flamelink project

JP Erasmus — Thu, 13 Sep 2018 14:14:15 +0000

So you are finally ready to take the training wheels off of your Flamelink project and take it live. Before you do that, have you set proper rules on your database? No really, you should!

If this is the first time you are hearing about Flamelink, a CMS for Firebase, check out our website to get started. After linking up your Firebase project to Flamelink head back here to read about securing your content.

Not too long ago, a new Firebase project shipped in test mode, ie. reads and writes were open to anyone on the real-time database. Since then the good folks at Firebase decided to change that and default to no read or write access in locked mode. This was done because many developers never bothered to tighten security rules for their projects running in production, leaving their databases open to anyone.

Now, Flamelink cannot work when your DB is in locked mode, because we would not be able to read/write to the DB from your browser. The only way to access your database in locked mode is from a server environment, which will require access via a service account. At Flamelink, we’ve decided against going that route and leave you, the end user, in full control of your project and the level of access you are comfortable in giving us while still sleeping at night. This comes at a cost in terms of the seamless user experience we can offer, and we might provide both options in the future, but I digress.

To quickly get started with Flamelink we suggest you set the following database rules for the RTDB (real-time database):

{
  "rules": {
    "flamelink": {
      ".read": "auth != null",
      ".write": "auth != null",
      "users": {
        ".indexOn": ["email", "id"]
      }
    }
  }
}

In plain English, this reads:

No access outside the “flamelink” namespace BUT read and write access to authenticated users inside the “flamelink” namespace.

The user’s index on the “email” and “id” fields are simply for better query performance and not important for this article on access control.

This is fine to quickly get started, but you can imagine it is not production-ready security to allow any authenticated user to write to your database. On the flip side, you might want some of the content to be readable by anyone regardless of whether they are logged in or not — think blog posts on your website, etc. So how can this be improved? Let’s look at a few options.

Things to know

There are a few things to know about setting security rules for the RTDB:

Security rules are completely ignored when accessed from a server, they are only applied when accessed by a client — the browser
If a rule gives read/write access to a parent node any other child nodes further nested in the DB structure will also have access. In other words, you can’t set a rule to false if it is already true from a rule higher in the DB structure.

Watch this video for a really good introduction to the RTDB security rules if you are not already familiar:

Read access for your app or website

The easiest one is to give read access to anyone for non-sensitive content, so we’ll tackle that first.

{
  "rules": {
    "flamelink": {
      ".read": "auth != null",
      ".write": "auth != null",
      "users": {
        ".indexOn": ["email"]
      },
      "environments": {
        "$environment": {
          "content": {
            "nonSensitiveContentType": {  
              ".read": true  
            }
          }
          "schemas": {
            ".read": true
          }
        }
      }
    }
  }
}

What you need to notice is the “nonSensitiveContentType” property, which you can replace with your specific content type’s key. This is specific to your data, so take a look in your database. You can do this for as many of the content types as you like. If you want you can make all content readable as well by just setting:

"content": {
  ".read": true
}

This is exactly what we’ve done for “schemas” in our example. If you use the official Flamelink JavaScript SDK, you will have to give read access to “schemas”, since this is used to determine if fields are valid, relational and some other goodies like caching.

Another option for read-access for your app users is to still require users to be authenticated but then use Firebase’s anonymous sign-in. The benefit this would give you is that your DB will only be readable from within your app (or whether you allow authentication for your project) and not via the REST endpoints for instance.

Write access for specific users

To restrict write access to your DB to only your Flamelink CMS users, you can specify the unique IDs (UID’s) in your rules like this:

{
  "rules": {
    "flamelink": {
      ".read": "auth != null",
      ".write": "auth.uid === '2TnyIXYi3FPeizykrJiLT972Oy53'",
      "users": {
        ".indexOn": ["email"]
      }
    }
  }
}

You can find the UID for your users under the “Authentication” section in your Firebase console. You can very easily specify multiple UIDs as well:

".write": "auth.uid === '2TnyIXYi3FPeizykrJiLT972Oy53' || auth.uid === 'LOkg1qVvLgTHWPyOkeBgrGaNuHy3'"

If you decided to anonymously log in all your app users, you can further restrict writes by checking for the “anonymous” provider:

".write": "auth.provider !== 'anonymous'"

Very dynamic rules

I want to start off, by saying that we do not suggest that you have to do this, but that it is possible. Continue…

In Flamelink, users are assigned to Permission Groups, each with a unique ID. These permission groups map to certain permissions in the app. A permission group could, for instance, be configured to allow only “view” access for schemas, but full CRUD access for content. We can make use of these permission groups to dynamically restrict access on the database level.

Bare with me, this might get nasty. We’ll first look at how we can enforce “view” permissions on your content types, but the same technique can be used for any of the other CRUD actions.

{
  "rules": {
    "flamelink": {
      ".read": "auth != null",
      ".write": "auth != null",
      "environments": {
        "$environment": {
          "content": {
            "$contentType": {
              "$locale": {
                ".read": "auth != null && root.child('flamelink').child('permissions').child(root.child('flamelink').child('users').child(auth.uid).child('permissions').val() + '').child('content').child($environment).child($contentType).child('view').val() === true"
              }
            }
          }
        }
      }
    }
  }
}

Wow! What the heck?! Okay, let’s break that down because the idea is simple, the syntax not so much. I promise it will make sense.

The idea: Get the user’s permission group and check if that permission group is set up to allow “view” permissions for the particular content.

The syntax: The rule is made up of two parts: getting the permission group ID and then checking the permission configuration for that group.

root
  .child('flamelink')
  .child('users')
  .child(auth.uid)
  .child('permissions')
  .val() + ''

This code starts at the root of your database and drills down to flamelink.users.<uid>.permissions, where <uid> is the user ID of the user trying to access the DB. The value of this database field is an integer, so we cast it to a string with + '' so that we can use it in the next part of our rule.

root
  .child('flamelink')
  .child('permissions')
  .child(<our-previous-query>)
  .child('content')
  .child($environment)
  .child($contentType)
  .child('view')
  .val() === true

Again, we start at the root of the DB and drill down until we get to the actual permission group’s configuration: flamelink.permissions.<user-permission-group>.content.<environment>.<content-type>.view.

Each permission group configuration consists of the following 4 boolean properties that map to a standard CRUD config:

{
  create: true,
  delete: false,
  update: true,  
  view: true
}

To check for any of the other permissions, simply replace “view” with “update”, “delete” or “create”.

You might have also noticed the auth != null part at the beginning of the rule. That is to ensure we’re still checking that the user is logged in, otherwise, all our hard work would be undone by someone simply not logged in.

That is it for the ".read" rule. The ".write" rule is similar to our reads, but more complex because we need to also take into account what the user is trying to do to the data to determine whether we should check the create, update or delete config.

We’re brave developers, so let’s continue.

{
    ".write": "auth !== null &&
    ((!data.exists() &&
      root
        .child('flamelink')
        .child('permissions')
        .child(
          root
            .child('flamelink')
            .child('users')
            .child(auth.uid)
            .child('permissions')
            .val() + ''
        )
        .child('content')
        .child($environment)
        .child($contentType)
        .child('create')
        .val() === true) ||
      (!newData.exists() &&
        root
          .child('flamelink')
          .child('permissions')
          .child(
            root
              .child('flamelink')
              .child('users')
              .child(auth.uid)
              .child('permissions')
              .val() + ''
          )
          .child('content')
          .child($environment)
          .child($contentType)
          .child('delete')
          .val() === true) ||
      (data.exists() && newData.exists() &&
        root
          .child('flamelink')
          .child('permissions')
          .child(
            root
              .child('flamelink')
              .child('users')
              .child(auth.uid)
              .child('permissions')
              .val()
          )
          .child('content')
          .child($environment)
          .child($contentType)
          .child('update')
          .val() === true))"
  }

Now that we’ve ripped off the bandage, what is happening here?

Apart from the auth != null check for logged in users, there are 3 distinct parts to our rule, each dealing with a different action (create, delete and update).

For our create action we make use of Firebase’s data.exist() method to check if no data currently exist for the particular content. That is how we know someone is trying to add new data.

For our delete action, we use the newData.exists() method to check if new data would not exist. If the user’s action would result in no new data, we know they’re trying to delete something.

For our last update action, we combine the data.exists() and newData.exists() methods to determine that a user is trying to change existing data to something else.

That was not so bad, was it?

For a full example of how this can be applied, see this gist.

This approach is not without its limitations. Since Flamelink is an evergreen and always-evolving product, new features are constantly added which could result in new nodes added to the database. If you tie down the database so much that we cannot make the necessary updates to your database structure, you won’t have access to the shiny new features. You can get around this by combining the UID specific rule we looked at earlier with this dynamic setup and ensure that if the user currently logged in is the owner of the project any writes can be made to the database. This would ensure that when new features are rolled out and the owner logged into the project, the necessary DB structure changes are applied.

With this said, we very rarely make structural changes because of the evergreen nature of the product.

Firebase Custom Claims

We’ve left the best for last. The most eloquent solution is to use the lesser known feature of Firebase: Custom Claims. We would love to ship Flamelink with custom claims out of the box, but customs claims can only be set from a privileged server environment using the Firebase Admin SDK. What that means is that you, the project owner, will have to handle this yourself.

What are Custom Claims?

Simply put, custom claims are custom attributes set on user accounts. You can, for instance, set an isAdmin attribute on a user. This is very powerful because it provides the ability to implement various access control strategies, including role-based access control, in Firebase apps. The amazing thing is that these custom attributes can be used in your database’s security rules.

Some ideas on how we can use them

Custom claims should only be used for access control and not to store any additional user data. It is best to store additional data in your database.

When setting your custom claims, you can keep it simple and set an attribute called flamelinkUser on all your Firebase users which should have write access to content. Alternatively, you can set as elaborate claims at you would like, but bare in mind that the custom claims payload should not exceed a limit of a 1000 bytes. It is recommended to keep it as small as possible since these claims are sent along with all network requests and a big payload can have a negative performance impact.

How to use these custom claims in our security rules?

Once set, it is extremely easy to check for custom claims in our database security rules. All custom claims are set on the authenticated user’s auth token.

{
  "rules": {
    "flamelink": {
      ".read": "auth != null",
      ".write": "auth.token.flamelinkUser === true"
    }
  }
}

How to set custom claims for your users?

The only requirement for setting custom claims is that they are set from a server environment using the Firebase Admin SDK, whether that is with a stand-alone Express server you have running or using Cloud Functions for Firebase, that is up to you. The code looks something like this (example uses JavaScript, but you can use any of the supported server side languages):

// import admin SDK
const admin = require('firebase-admin');

// initialize admin app with any of the supported options
admin.initializeApp(/\* config here \*/);

// create your custom claims object (whatever you want)
const customClaims = {  
  flamelinkUser: true  
};

// set the custom claims object for given UID
admin.auth().setCustomUserClaims(user.uid, customClaims)

The admin.auth().setCustomUserClaims() method returns a Promise. It is important to note that setting new custom claims overwrite any existing custom claims, so you might want to first retrieve the existing claims and update it before setting it again.

Conclusion

Hopefully, this gave you an idea of how powerful and flexible Firebase security rules are. I encourage you to read more about these rules in Firebase’s documentation.

If you have any other ideas on how we can improve these security rules, please let us know in the comments below or join our Slack community, we’d love to have you.

Useful “reduce” use cases

JP Erasmus — Tue, 28 Aug 2018 06:44:24 +0000

I recently saw a tweet from a developer stating that he understands the array reduce function, but can not think of many useful use cases for it. In this post, I’ll aim to give a couple of real-world use cases for reduce.

The post will assume you are comfortable with JavaScript Promises; if not, I have a very simplified primer on them in a previous post that you can check out.

Promise chains

Promise.all() is very useful to run numerous promises in parallel, but what if the order in which your promises should resolve is important? In that case, you need to run them sequentially. The following function will do exactly that.

const promiseQueue = (promiseFn, list) =>
  list.reduce(
    (queue, item) => queue.then(async result => {
      const itemResult = await promiseFn(item);
      return result.concat([itemResult]);
    }),
    Promise.resolve([])
  );

Sum numbers

The most taught and classic example of using reduce is to get the total of an array of numbers, so this list won’t be complete without it. It doesn’t need to be an array of numbers though - you can use more complex data structures.

const cities = [
  {
    city: "Chongqing",
    population: 30165500
  },
  {
    city: "Shanghai",
    population: 24183300
  },
  {
    city: "Beijing",
    population: 21707000
  },
  {
    city: "Lagos",
    population: 16060303
  },
  // ...etc
]

const totalPopulation = cities.reduce(
  (sum, city) => sum + city.population,
  0
);

Filter and Map

When you have a data set that needs to be filtered by some criteria and you want to manipulate each remaining item as well, an okay, but slightly naive option would be to first run filter on it and then map over it again essentially doing a lot more looping-over-items than required. A better option would be to use reduce.

Say for instance you have the results of all the students that wrote a particular paper, but you are only interested in the full names of all the students that had a mark of more than 80 out of a hundred.

const studentsData = [
  {
    firstName: "Albert",
    lastName: "Einstein",
    score: 53
  },
  {
    firstName: "Charles",
    lastName: "Dickens"
    score: 84
  },
  {
    firstName: "Marilyn",
    lastName: "vos Savant",
    score: 99
  },
  // etc.
];

const smartestStudents = studentsData.reduce(
  (result, student) => {
    // do your filtering
    if (student.score <= 80) {
      return result;
    }

    // do your mapping
    result.push(`${student.firstName} ${student.lastName}`);
    return result;
  },
  []
);

Array to Object conversion

Sometimes you need an object as output from an array and not another array. All other array higher-order functions will always produce an array as output.

Say for instance you have an array of form fields with their validation constraints and you want an object of constraints where the name of the field is the top level keys in the object.

const fields = [
  {
    type: 'text',
    title: 'Title',
    name: 'title',
    constraints: {
      required: {
        message: '^Title is required',
        allowEmpty: false
      }
    },
  },
  {
    type: 'text',
    title: 'Slug',
    name: 'slug',
    constraints: {
      required: {
        message: '^Slug is required',
        allowEmpty: false
      },
      format: {
        pattern: '[a-z0-9\_-]+',
        flags: 'i',
        message: '^Can only be a valid slug'
      }
    },
  },
  // etc.
];

const validationRules = fields.reduce(
  (rules, field) => Object.assign(rules, { [field.name]: field.constraints }),
  {}
);

This would produce something like this:

{
  title: {
    required: {
      message: '^Title is required',
      allowEmpty: false
    }
  },
  slug: {
    required: {
      message: '^Slug is required',
      allowEmpty: false
    },
    format: {
      pattern: '[a-z0-9\_-]+',
      flags: 'i',
      message: '^Can only be a valid slug'
    }
  },
  // etc.
}

Note: if you care about not mutating data, you might consider using Object.assign({}, rules, { [field.name]: field.constraints }) or using the object spread syntax, { ...rules, [field.name]: field.constraints }. I would advise against this. Personally, I’m a firm believer in the value of immutable data, but with pragmatism. In this case, a new object will be created for each iteration which could end up using quite a lot of unnecessary memory in your app.

Piping or Composing functions

Sometimes you have a sequence of functions that you want to be invoked for a specific value. The useful functional programming methods, compose and pipe are perfect for this, but unfortunately, they are not natively part of the JavaScript language (yet!). Not to worry, we can easily write our own:

const pipe = (...fns) => x => fns.reduce((v, f) => f(v), x)

pipe is a function that takes a list of functions, calling each function in sequence with the output of the previous function used as the input for the next.

compose is very similar; it just invokes the functions in reverse order, from last to first, so it can be implemented like this:

const compose = (...fns) => x => fns.reverse().reduce((v, f) => f(v), x)

An example could be calculating the checkout total for an online store:

const calculateTotal = pipe(
  applyAnySales,
  minusStoreCredit,
  applyCouponCode,
  addTaxes
)

const cardValue = 250;

const total = calculateTotal(cardValue)

If you have any other practical examples of using reduce please leave a comment so that I can learn from you.

“forEach” all the things!

JP Erasmus — Fri, 11 May 2018 15:38:51 +0000

Disclaimer: this is an opinion piece, feel free to disagree.

Having done a good number of code reviews over the past few years and seeing what comes back to bite us vs. what generally works the way we intended, one such issue is knowing when to use forEach. It comes down to asking yourself the right questions.

On a separate but related point, I would argue that being comfortable with AND knowing when to use forEach, map, filter or reduce, you can tackle any array-related data manipulation problem, so it really pays, as a developer, putting in the effort to get very comfortable with it. Sure there are some other very useful methods, like flatMap, but knowing these four, you can go a long way.

This post will use JavaScript as an example, but the concept is the same for any language that supports the higher-order array functions: forEach, map, filter and reduce.

Who is this post for?

Developers that already know to favour forEach over for loops to write more beautiful (declarative!) code, but are perhaps not comfortable with these higher-order array functions. There is a place for a for loop, but more often than not, you should use the more declarative option.

“forEach” all the things!

The first thing developers start doing when they move from the imperative for loop to more declarative forEach functions, is that they “forEach all the things”!

This is okay and definitely better than using for loops everywhere, but we can do better.

The thinking process

Sure you can use a shoe to hang a picture on the wall, but a hammer is a better tool for the job.

Use the right tool for the job.

What follows are questions you can ask yourself while coding and trying to decide whether you should use forEach, map, filter or reduce.

1. I’ve got an array of things and I want to manipulate each item in some way

The wrong way: use forEach

const list = ['a', 'b', 'c']
const newList = []

list.forEach(item => {
 newList.push(item.toUpperCase())
})

console.log(newList) // ['A', 'B', 'C']

The right way: use map

const list = ['a', 'b', 'c']

const newList = list.map(item => item.toUpperCase())

console.log(newList) // ['A', 'B', 'C']

2. I’ve got an array of things and I want to “reduce” it to one thing

This one is easy to remember once you are comfortable with it and it works really well for situations like summing totals or reducing a list of objects into a single object. You can think of reduce as compressing a list of inputs into a single output.

The wrong way: use forEach

let total = 0
const list = [1, 2, 3, 4]

list.forEach(item => {
 total = total + item
})

console.log(total) // 10

The right way: use reduce

const list = [1, 2, 3, 4]

const total = list.reduce((sum, item) => sum + item, 0)

console.log(total) // 10

This example, to sum a few numbers, doesn’t make the pain obvious, but working with more complex data will surface the problem.

3. I’ve got an array of things, but I only want a subset of them

The wrong way: use forEach (noticing a pattern here?)

const list = [1, 2, 3, 4]
const evenNumbers = []

list.forEach(item => {
 if (item % 2 === 0) {
 evenNumbers.push(item)
 }
})

console.log(evenNumbers)

The right way: use filter

const list = [1, 2, 3, 4]

const evenNumbers = list.filter(item => item % 2 === 0)

console.log(evenNumbers)

4. I’ve got an array of things and I want to perform an action for each item but I don’t care about a return value

The wrong way: use map, filter or reduce

Just like it is technically possible to use forEach for everything else, as we saw above, it is possible to use any of the other higher-order functions here, but it would not be the right tool for the job.

“It is just semantics” is not a thing.

const list = ['user1', 'user2', 'user3']

const newList = list.map(user => fireAndForgetNetworkRequest(user))

console.log(newList) // [undefined, undefined, undefined]

The right way: use forEach

const list = ['user1', 'user2', 'user3']

list.forEach(user => fireAndForgetNetworkRequest(user))

// nothing to log

Hint: If you can’t declare your variables with const and you need to use let, you might be using the wrong method.

TL;DR;

If you made it this far, hopefully, the post wasn’t too boring. Let me know in the comments if you disagree with anything or if you have some better examples that I haven’t thought of.

Published: 10 May 2018