Welcome to Rant.js, a new series I’m starting based on short, mostly opinions, on anything that interests me in the JavaScript world. These articles, while not entirely factual, may provide an interesting look into the day-to-day thought process of a JavaScript developer. These rants mostly stem from discussions with peers on Slack or GitHub. You can find the previous article here: JavaScript — Undefined vs. Null

My Opinion On Automated Tests

I use automated testing to some extent in almost every single one of my projects. This includes personal, freelance/consulting, and full-time projects. I never strive for 100% coverage. I believe testing the least amount of things possible is the best approach. Tests must be maintained alongside your code, they’re an investment. I’ve seen many testing suites break down and fail because they were too verbose, annoying to update, or didn’t stop production bugs in critical areas due to a focus on total coverage.

How Do You Know What To Test?

It’s really hard to give specific advice without knowing specific business requirements or what a codebase looks like. Thankfully, there are a few common areas to check for testing when looking at a codebase.

Business Critical

The most important areas to test are those that are business-critical. If you’re working on an e-commerce site, this would be anything surround the checkout, cart, and adding/removing products. If any of these areas were to go down, you’ll definitely be getting a PagerDuty request to fix a P1 issue. Say goodbye to relaxing at home on the weekend!

High Error Occurrence

Another way to add new testing coverage is to look into existing error reporting data. I’m generally able to trace a large amount of user errors to a single feature or chunk of a codebase. These features/chunks can have tests added for expected behavior. This is easily followed by bug fixes & refactors to stop these errors from being thrown in production.

Large Surface Area

One last thing that may warrant test coverage is a function or component that has many uses or has a large surface area. If something were to break in these functions/components there will be many issues downstream. This may also be a sign that abstraction is needed. It may be time to break logic down into smaller, more testable chunks.

Slightly Specific Examples

Alright, this is all a bit abstract, I think a few examples would help. Within a React/Redux eCommerce app I’d start with the following:

1. Test Redux Actions for “Checkout Process” (Enzyme)
2. Test User Flow for “Checkout Process” (Cypress)
3. Test Redux Actions for “Cart Actions — Product Add/Remove” (Enzyme)
4. Test User Flow for “Cart Actions — Product Add/Remove” (Cypress)
5. Test Redux Actions for “User Login” (Enzyme) [has a different priority if this is required for purchase, this assumes guest checkout is possible]
6. Test User Flow for “User Login” (Cypress)

This would prevent the most direct customer facing issues that would impact them from making a purchase. Any new tests can be added using the above criteria.

Is This All Really Worth It?

Sometimes it may seem like adding and maintaining these tests is a lot of work and is all for nothing. You still see bugs come through in production regardless of tests, there’s always issues to fix. It may seem like your tests don’t even work at times. I know it can also be exhausting having to fight for testing time in some organizations, it can seem like a lost cause in many cases.

Let me explain a recent situation that really sold me on automated testing. I was already a staunch advocate, I didn’t think it was possible to sell me the concept any further.

Why Is Everything On Fire? 🔥

Seemingly out of nowhere we started to see a lot of new high occurrence errors. We recently pushed out an update that we suspected had a chance to cause issues due to the amount of areas this new feature touched. Multiple P1 and P2 issues were being filed daily, we were playing whack-a-mole trying to keep up and fix them.

Where Did My Weekends Go?

This went on for 2 weeks and didn’t seem like it was slowing down any time soon. I unfortunately was on-call during these 2 weeks, I suffered the loss of many nights and my weekends. I was also unable to accomplish any normal day-to-day work as all of my time was taken up dealing with priority issues within our production environment.

Why was this happening? We have tons of automated test coverage that runs automatically within TravisCI, they were all passing, or so we thought…

Tests Weren’t Even Running

During a checkup of our CI environment (we’ve been making many improvements to our testing pipeline) it was discovered that due to a misconfiguration, Travis was only running 20% of our tests but was returning that they were all passing. Once re-configured it was revealed that many of our tests had been failing this entire time.

Back To Normal

Wow. After this was discovered, we were able to quickly fix issues based on failing tests. Our error rates seemed to drop off completely, we were back to normal rates. No more massive influx of P1/P2 issues, no more lost nights and weekends.

This 2 week period while terrible to experience, validated to everyone the benefits of testing. Especially to those outside of the development team. The same people that were complaining about features not being released quickly were now demanding that testing be extended at the cost of frequent feature releases. Testing is now a concrete standard within the organization.

What We Learned

The issue we experienced also showed the importance of doing regular maintenance and checkups of your testing / CI system. It also shows the importance of doing local testing for large features rather than depending on automated testing systems. Things can always go wrong, it doesn’t hurt to double check before major deployments.

Feedback? Words of encouragement? 🎉

I’m always looking to improve my articles, if you would like to leave feedback (I would love it if you did!) you can find the Google Form here. It’s very short, I promise!

We All Need Automated Tests (Rant.js) was originally published in DailyJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to Rant.js, a new series I’m starting based on short, mostly opinions, on anything that interests me in the JavaScript world. These articles, while not entirely factual, may provide an interesting look into the day-to-day thought process of a JavaScript developer. These rants mostly stem from discussions with peers on Slack or GitHub.

Why Does This Even Matter?

Do we really need to talk about this, does it even matter? They’re both falsy values that behave extremely similarly, isn’t this a little pedantic? I don’t think so.

Declared Vs. Undeclared

To start, let’s take a moment to talk about declared vs undeclared values as they’re a little tricky within JavaScript. To make things confusing, undefined can be both a declared and an undeclared value. In the following example we show 2 variables with undefined values, one is declared and the other is undeclared. The undeclared variable will throw a ReferenceError stating that the variable is not defined, the other simply returns undefined .

While the undeclared variable throws an error, it still holds the same type as the declared variable. See the following example using the above variables:

Well That’s Confusing…

Is the type situation better for a null value, is that why I prefer it? Not exactly, it has its own issues to deal with… great! Consider the following:

That’s odd, when you check the type of null it returns that it is an object. Does this mean null is an object and is not one of JavaScript’s six built-in primitives types? Wrong! It’s a primitive type and is not an object, this is a near 20 year old bug with JavaScript that most likely won’t ever be fixed due to the harm it would cause to programs that have adjusted for it.

How Do We Type Check For Null?

The situation above makes things a little tricky when you want to explicitly check for a null type. Thankfully since null isn’t really an object, it’s the only “object” that is a falsy value, empty objects are truthy. We can use this check along with a type check to check for a its type:

While a little more to write, this is the only way we can explicitly check for a declared empty value. As shown before, the undefined type can be returned on declared and undeclared values. If you’re concerned about having to write the extra conditional, create a simple null checking function:

Isn’t This An Opinion Piece?

Yes, but I felt that a little information was needed to drive the point home, back to the original topic.

JavaScript Already Decided For Us

We have 2 different types that can represent empty values, which should we choose? JS already chose that for us, most issues are caused due to an object or array that evaluates to undefined . This ends up throwing an error when attempting to access object properties or calling object/array methods. See below:

With every added level of depth, the likelihood that an error could be thrown is increased. This is because an error will be thrown if any parent property in the chain evaluates to a non-object.

Intentionally Empty

As the above scenario happens fairly frequently, we need a way to differentiate empty values caused by errors and empty values that are intentionally empty. This is where null comes into play.

Consider the following example:

This may look innocent and easy to remember, but sometimes objects are imported within multiple files. On top of this, they may be passed through multiple functions. Original values may not be immediately obvious, especially to someone unfamiliar with your codebase (freelancers & consultants).

It would be easy to do the following and assume something broke during data processing rather than the value was intentionally assigned as undefined:

If I saw the following output, I would assume this empty null value was intentional and would not waste my time investigating a possible issue:

A Better Alternative

When possible (see Polymorphic Values), it is better to represent empty values as an empty version of its expected type. This prevents array, object, and string methods from throwing an error when they’re presented with a null or undefined value.

Compared to assigning the same variables with null values:

Polymorphic Values

The above technique works great in most situations, but sometimes we don’t have that much fine grained control of how our values are assigned. For example, a variable’s value could be set directly from the response from an API. This API could return different types depending on parameters passed or other situations outside of the developer’s control. In this situation, it’s best to set an initial value of null and null check downstream.

EXTRA: Safely Access Deep Object Properties

A common method to safely access object properties is to use a ternary. This unfortunately becomes a little cumbersome when accessing properties that are multiple levels deep.

We can define a function to safely access object properties. If any property in the chain can not properly evaluate, it will return null. This first argument is the object we’re attempting to access properties on. The second argument is a string of props, split by periods. We’ll first define an isUndefined method to match our isNull method from earlier.

Now we define our get function:

The above example canSafelyAccessNestedProperty can be converted using our get function like so:

We can save a getter to a specific object by only supplying the first argument. This is useful when you need to access an object multiple times with different property chains.

Feedback? Words of encouragement? 🎉

I’m glad you made it, hopefully you learned a few patterns or pieces of information to use in the future. I’m always looking to improve my articles, if you would like to leave feedback (I would love it if you did!) you can find the Google Form here. It’s very short, I promise!

Rant.js — undefined vs null was originally published in DailyJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ll start this article with a warning, I mention the use of Lambda Calculus, but do not let that scare you! I promise, no knowledge of λ-Calculus is required to understand or use the main concepts in this article! Phew!

In my last Functional JS article, we went over recursive patterns that allow you to operate/iterate over array values. This time, we’re going to get a bit more abstract to hopefully explain some of the bare fundamentals of functional programming.

A moment on Currying

You’ll notice that we never define a function with more than 1 argument. We return a new function for every additional argument needed. This is a technique used very commonly in functional programming that has its roots in Lambda Calculus. This has multiple benefits, but is used mainly to simplify partial application of functions.

What are we doing?

Glad you asked! We’re going to re-create: true, false, ||(or), &&(and), !(not), ==(equals), and !=(not equals). As a bonus, we’re going to use some magical Lambda Calculus to make our functions much more efficient!

Let’s get started!

The first functions we need to define are our booleans: true and false. How we define these functions makes more sense once they’re used with the conditional function we soon define. The way we represent booleans as functions is a concept known as Church Booleans.

TRUE (true):

No, I’m not trying to yell, I’m using this naming convention because true in all lowercase is a reserved word and can’t be used to name our function. This function takes two arguments and will always return the first argument. In comparison, the FALSE function does the same, but always returns the second argument. These functions are also known as selectFirst and selectSecond in other languages.

FALSE (false):

Almost identical to the TRUE function, but returns the second argument rather than the first.

Conditional (cond):

The next function we need to define is our function that will handle conditional logic. Normally we’d use an if/else statement or a ternary to do this, but we want everything to be a function. It’s functions all the way down, this comes in handy later on.

If you break down a conditional in JavaScript, you end up with 3 parts:

1. Conditional Statement
2. Expression when true
3. Expression when false

To mimic this, we will create a function that takes 3 arguments and returns the conditional function with both expressions applied. If you notice, I place the conditional last rather than first. This is a functional programming convention that helps when creating partially applied functions.

If you remember how we defined our booleans, they are both functions that when called with 2 arguments, return one of these arguments. This is exactly how our conditional function is going to work. The conditional function (TRUE or FALSE) passed in is called with 2 arguments, our expressions when true and false.

Not (!)

This is the first logical operator we will define. It takes a single argument: x. If x is TRUE it returns FALSE, if x is FALSE it returns TRUE. We make use of the previously defined cond function to handle the conditional logic. Within the conditional: if x is TRUE we return FALSE otherwise we return TRUE .

Or (||)

This is the first logical operator we will define. It takes 2 arguments: x and y. If either x or y is TRUE, we will return TRUE, otherwise we return FALSE. Again, we use the cond function to handle this. Within the conditional: if x is TRUE we return TRUE otherwise we return y .

And (&&)

This function takes 2 arguments: x and y. Both x and y must be TRUE for this to return TRUE, otherwise it will return FALSE. We make use of the cond function again, not much is different. Within the conditional: if x is TRUE we return y otherwise we return FALSE.

Equal (==)

This function takes 2 arguments: x and y. Both x and y must be the same value for this to return TRUE otherwise it returns FALSE. We need to use the cond function and the not function to handle this one! Within the conditional: if x is TRUE we return y otherwise we return not(y)to only return TRUE when y is also FALSE.

Not Equal (!=)

This function takes 2 arguments: x and y. x and y must not be the same value for this to return TRUE, otherwise FALSE is returned.

EXTRA: β (Beta) Reductions through λ-Calculus

Disclaimer: do not feel the need to understand this at all as it is not a requirement to understand and use functional concepts. However, I think it’s an interesting topic to learn about and helps demonstrate the power of functional programming through math. I will gloss over topics as I am not the best resource to learn λ-Calculus, it is not the focus of this article, just an added bonus. These optimizations are handled automatically with most statically compiled functional languages.

And (&&) Reduction

In the following example, we use β reduction to remove the use of our cond function entirely from our and function. Our and function is now composed entirely with booleans and is mathematically equivalent!

Or (||) Reduction

Again, we use reduction to remove the use of our cond function entirely from our or function. Like before, our or function is now composed entirely with booleans and is mathematically equivalent.

Equal (==) Reduction

Just like before, we use reduction to remove the use of our cond function entirely from our equal function. Our equal function is now composed entirely with booleans and is mathematically equivalent.

Not Equal(!=) Reduction

For the last time, we remove the use of our cond function entirely from our notEqual function. Our notEqual function is now composed entirely with booleans and is mathematically equivalent.

Wrapping Up

I hope this helped demonstrate the power and flexibility of functions. This logic can be shared and re-written in any language that has first-class functions!

The functions and concepts used in the article will be expanded in a later article where we use Church numerals to represent natural numbers as pure functions. We will even implement arithmetic and comparison operators for these numbers! 🚀

Feedback? Words of encouragement? 🎉

I’m glad you made it, hopefully you learned a few patterns or pieces of information to use in the future. I’m always looking to improve my articles, if you would like to leave feedback (I would love it if you did!) you can find the Google Form here. It’s very short, I promise!

Functional JS with ES6 — Church Booleans, Conditionals, and Operators was originally published in DailyJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intro

To put it simply, a higher-order component is a function, that takes a component and returns a new component. I like to think of them as parameterized components. Many times I find myself creating several components with very similar logic, with only 1 or 2 changes. Once I find a use case like this, it’s very simple to abstract the shared logic, and put the logic that changes into parameters.

You can read more about HOCs here, in the official React docs. Since components are just functions and HOCs are just functions that return other functions, we can use functional concepts to chain them using utilities methods such as compose, which is provided by many libraries (it's included in Redux!).

I’m going to talk about a few common use cases, then go over their implementation, and a few ways they can be composed together to make even more powerful HOCs!

Follow Along (Example App)

You can following along with a simple React app I create to demonstrate the following concepts and use cases. It can be used in browser or cloned from the repository.

Live sandbox: codesandbox.io/s/github/caseymorrisus/composing-hocs

GitHub repo: github.com/caseymorrisus/composing-hocs

Use Cases

Now that we know a little about higher-order components, we can go over a few common use cases.

Loader

It’s common to pull data from an API and display a “spinner” or message until the data has been fetched. You may have a standard Loading component which has a prop message for displaying a loading message specific to your current application.

Error

Almost identical to the Loader HOC, but instead displays an Error component and expects an error prop. Can be supplied a custom Error component.

Default

It’s good practice to display some type of message if data was successfully fetched, but none of the given type were returned from the data source. For example, instead of display a blank list of posts, if no posts have been created, you could have a DefaultPost component which could prompt the user to create a post.

Data

Container components frequently fetch data and pass that data as a prop to a child component. Generally the only thing that changes between these container components is the API endpoint. We can also use HOCs to easily pass in mock data for development purposes.

MockData

Used for development purposes to quickly prototype components before an API endpoint has been created or implemented within your React project. Data and a delay (to mock async data fetching) are supplied to the HOC. Data is passed down to the wrapped component.

Logger

Easily log all prop changes (on render) for a given component, helpful for quick debugging purposes.

Props

Sometimes you need to inject props into a component, this is especially useful when using a branch HOC and only want a single branch to receive specific props.

Timeouts

Adding a timeout that controls state within React will throw an error if a component unmounts before the function supplied to the timeout has fired. We can create an HOC that handles and shares functionality to easily add and clear timeouts.

Container

It’s fairly common to have a container component, which fetches data, and renders a list of components using that data. We can combine this with other HOCs such as: hasloader ,hasError, andhasDefault to extend functionality further.

List

As stated above, it’s fairly common to take an array of data and render a component for each item in the array. This HOC will also spread the current data item as props into the supplied component.

HOCs

Now that we’ve gone over a few use cases, lets look at some simple implementations before we get into any complex chaining.

hasProps

Takes a single parameter, injectedProps and returns a wrapped component with the supplied injectedProps . Useful when you need to inject props to a single component within the branch hoc, as the props supplied are injected into both passing and failing components.

Use:

Use with branch HOC:

hasLogger

Takes a single parameter, prefix which prefixes the logged message, defaults to an empty string. Logs props to the console on every render of the WrappedComponent.

Use:

branch

Takes 3 parameters: test, ComponentOnPass, and ComponentOnFail and returns either of the supplied components depending on the result of the test function. If the test function returns true, ComponentOnPass will be returned, if false, ComponentOnFail will be returned. Immediately returns a new component unlike other HOCs in this post.

Use:

hasMockData

Takes 2 parameters: mockData and delay and returns a wrapped component with a new data prop. mockData is injected into the data prop after the delay has passed. Can set delay to 0 or leave blank to have no delay. Uses the hasTimeouts HOC to extends functionality to include addTimeout and clearTimeout props.

Use:

hasLoader

This higher-order component has no parameters. It returns a wrapped component with new loading and loadingMessage props expected. It conditionally renders the supplied component if loading is false. Otherwise, it renders the Loading component with the loadingMessage supplied.

Use:

hasError

Takes 1 parameter: ErrorComponent which has a default value of the Error component. Can supply a custom ErrorComponent if desired rather than using the default value. It returns a wrapped component with a new expected prop: hasError. It conditionally renders the supplied component if hasError is false. Otherwise, it renders the ErrorComponent.

Use:

Uses a default Error component if none is supplied:

hasDefault

Takes 1 parameter: Default which expects to be a React component. It returns a wrapped component with a new expected prop: useDefault. It conditionally renders the supplied component if useDefault is false. Otherwise, it renders the Default component.

Use:

hasData

Expects a single parameter object which expects properties of url, params, and loadingMessage. url dictates which endpoint is hit, params injects URL parameters for the request, and loadingMessage allows you to customize the loading message within the Loader component. Uses Axios to get data from an API endpoint. Axios can easily be replaced with your fetch implementation of choice. Injects data, hasError, error, useDefault, loading, and loadingMessage as props to be used in the wrapped component.

Use:

hasTimeouts

Expects no parameters and returns a wrapped component with injected props addTimeout and clearTimeouts. These props allow you to easily create timeouts and be able to clear them when a component unmounts. If you have an active timeout and unmount a component, it will throw an error.

Use:

isList

Expects a single parameter type which dictates the className used in the wrapped div for the list. This HOC expects the list component to have a data prop which contains an array of items. All properties of individual items are injected as props to the individual wrapped component.

Use:

Composition Using Higher-Order Components

The true power of HOCs comes when you start to chain (compose) them. You can chain as many of them as you like. If you have a component which needs an error and default state, simply compose it like so:

The returned component can now be controlled to show an error or a default using its props. In the case of the above example, if useDefault and hasError are both true, hasError and the ErrorComponent would take precedent since it is first within the compose function.

Do you want to add logging to the above component and also supply it with mockData? Easy! Simply change the above to:

HOCs can easily be added and composed to extend the functionality of any component!

isContainer

Expects a single parameter object with props data, Error, and DefaultComponent. data is expected to be the param object expected by the hasData HOC. Error expects a custom error component, but if left blank will display the default error component. DefaultComponent expects a component to display in the container list if no items were fetched from the API.

Use:

Quick Note About Debugging

For debugging purposes, we are making our code a bit more verbose. Using the hasProps HOC as an example, we could further simplify it like so:

The problem with this is that when viewed in the React Developer Tools, the component comes back as Unknown as it was never given a name. Using the original example provided for the hasProp HOC would display a HasProps component within the React Developer Tools.

Using Redux Compose

As mentioned above, Redux supplies a compose method that can be imported and used like so:

You can read more about their implementation over at their documentation here. The compose function isn’t very special in itself, it can be imported from many libraries.

Example App

Home Page

The provided example app shows use of all concepts above. The home page includes components that have been extended with HOCs and also includes buttons to control the props that control the HOCs used to extend them. To put it simply, you’re able to click a button and switch which component renders based on props. This page includes a MockPostContainer which extends the Post component with a logger, mock data, loader, error, default, and list.

Posts, Todos, Comments, and Users Pages

All of these pages consume real API endpoints from https://jsonplaceholder.typicode.com/ . They each extend a single component (Post, Todo, Comment, User) with the isContainer and isList HOCs.

Wrapping Up

I hope the above patterns / components help you create some new higher-order components of your own. These are the most common use cases for me, I’m sure you probably have a few common use cases not listed above. I’d love to hear how higher-order components have helped you simplify your code!

If you appreciated the article and it helped in any way, don’t hesitate to share and clap! 👏

Feedback? Words of encouragement? 🎉

I’m glad you made it! I’m always looking to improve my articles, if you would like to leave feedback (I would love it if you did!) you can find the Google Form here. It’s very short, I promise!

React — Composing Higher-Order Components (HOCs) was originally published in DailyJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s the deal here?

Functional programming has been on the rise and is a topic that is very exciting to me. It allows me to write terse, declarative code that is easy to test and reason about. What is functional programming? I’ll defer that answer to someone with more knowledge on the subject, Eric Elliot:

Functional programming (often abbreviated FP) is the process of building software by composing pure functions, avoiding shared state, mutable data,and side-effects. Functional programming is declarative rather than imperative, and application state flows through pure functions. Contrast with object oriented programming, where application state is usually shared and colocated with methods in objects.

ES6 brings many features that allow us to easily write pure functions, rest/spread being one of the most powerful. Using rest params, we’re able to “loop without loops” with recursion. In this article, we’re going to rewrite many commonly used JavaScript methods/functions that allow for functional patterns.

Preface

The following functions are for demonstration and learning purposes. Many functions below are tail-recursive and should be optimized further. Fixing tail-recursion is not the subject of this article. ES6 brings tail-call optimization, but must be used in conjunction with 'use strict' .

Head

Return the first item in an array. Is useful when you need to separate the first item from the rest of the array items. To do this, we make use of destructuring assignment.

Example usage:

Tail

Return all but the first item in an array.

Which is essentially the same as writing:

Since we don’t need to use x in the returned output, we can drop it, but keep the comma to get the rest of the items in the array.

Example usage:

Def

Return if argument supplied is defined.

Example usage:

Undef

Return if argument supplied is undefined.

Example usage:

Copy

Returns a copy of an array without using Array.slice(). Makes use of spread.

Example usage:

Length

Return the length of an array. This is a very simple form of looping through an array with recursion, even though the values of the array don’t matter in this case (increments up starting at 1 for every item in array). We include the len param to avoid tail recursion.

If we don’t care about tail recursion, we can write it as:

This would add a stack frame for each item in the array, whereas the version that avoids tail recursion, replaces a single stack frame. If the array passed in is large enough, it will throw “Maximum call stack size exceeded”.

Example usage:

Reverse

Return a reversed array.

Example usage:

Array.reverse() is okay, but it modifies the value in place which is a side-effect. Consider the following:

First

Returns a new array that contains the first n items of the given array.

Example usage:

Last

Returns a new array that contains the last n items of the given array.

Example usage:

Slice

Returns a new array with value inserted at given index.

Example usage:

isArray

Returns if the value supplied is an array. Allows us to write Array.isArray() in a more functional manner.

Example usage:

Flatten

Combines nested arrays into a single array.

Example usage:

Swap

Return a new array with 2 items swapped based on their index.

Example usage:

Map

From MDN: “…creates a new array with the results of calling a provided function on every element in this array.”

Which can be simplified as:

Example usage:

Filter

From MDN: “…creates a new array with all elements that pass the test implemented by the provided function.”

Which can be simplified as:

Example usage:

Reject

The opposite of filter, returns an array that does not pass the filter function.

Example usage:

Partition

Splits an array into two arrays. One whose items pass a filter function and one whose items fail.

Example usage:

Reduce

From MDN: “…applies a function against an accumulator and each element in the array (from left to right) to reduce it to a single value.”

Which can be simplified as:

Example usage:

ReduceRight

Similar to reduce, but applies the function from right-to-left.

Example usage:

Partial

Partially apply a function by filling in any number of its arguments.

Example usage:

SpreadArg

Convert function that takes an array to one that takes multiple arguments. This is useful when partially applying.

Example usage:

If you only want to define a single function you can write it as:

In the above, you need to remember to spread the array you are sending into the function recursively, since you are spreading the argument.

ReverseArgs

Reverse function argument order.

Example usage:

Reversing arguments can be useful when partially applying arguments. Sometimes you want to partially apply arguments at the end of the list, not those at the beginning. Reversing the arguments allows us to do that.

Pluck

Extract property value from array. Useful when combined with the map function.

Example usage:

Flow

Each function consumes the return value of the function that came before.

Example usage:

Compose

The same as flow, but arguments are applied in the reverse order. Compose matches up more naturally with how functions are written. Using the same data as defined for the flow function:

Example usage:

Min

Return the smallest number in an array. Returns Infinity if array supplied is empty.

Example usage:

Max

Return the largest number in an array. Returns -Infinity if array supplied is empty.

Example usage:

Factorial

Returns the factorial of a number. Uses an accumulator to allow replacing of stack frames to allow larger factorials to be returned.

Example usage:

Fibonacci

Returns the Fibonacci number at the given place.

Example usage:

Quicksort

Sort an array from smallest to largest. This is done by re-ordering the array so that it contains two sub-arrays, one with smaller values, the other with larger values. The above steps are recursively applied to each sub-array until there are no arrays left, which is flatten to return a sorted array.

This can also be implemented using partition, but requires variable assignment.

Example usage:

Everything as a Reduction

Many of the functions above can be converted into reductions, which should increase performance in most, if not all cases. This also shows the flexibility of the reduce function.

Example usage:

Wrapping Up

I hope this article helps shed insight on some of the patterns made available with JavaScript and ES6. Many problems that can be solved with iteration/loops, can also be solved functionally through recursion. I hope this article was also able to show you the flexibility of the reduce function.

Feedback? Words of encouragement? 🎉

I’m glad you made it! I’m always looking to improve my articles, if you would like to leave feedback (I would love it if you did!) you can find the Google Form here. It’s very short, I promise!

Functional JS with ES6 — Recursive Patterns was originally published in DailyJS on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is the beginning of a series titled “Creating Reusable Components with Vue.js”. Each article will guide you through creating a specific UI component and will teach you many Vue essentials along the way. Each article will build upon the last, getting more complex the further we go. Application structure and other opinions will be shared as well.

Update — April 13, 2017

Changed the application structure and WebPack alias setup a bit. The old setup was causing a circular dependency issue with WebPack which would cause nested components (that are both within the definition file) to fail. This type of definition file is still relevant in the context of creating a plugin, but it is used a bit differently. We won’t be worrying about creating a plugin for now.

Whoa , slow down

Isn’t there a native button element already, why would you need a custom component for that?

1. Shared functionality
2. Shared styles

Both of these will help the maintainability of our application. If a feature needs to be added, updated, or deleted, it only needs to be fixed in a single place. Cha-ching!

Preface

This article is aimed at people who have a basic understanding of Vue and NPM already. The main focus of this article is JavaScript and how it interacts with the DOM. This means that CSS might not be explained. I cannot guarantee that anything in this article will work in future releases. I cannot guarantee that any of my personal practices are best practices. I am not responsible for any long tangents that seemingly have no point. Phew, now lets get to the good stuff.

Boilerplate

I have created a boilerplate base project to use. Setting up a project is not the subject for this article. This article assumes you have a very basic understanding of the single file component syntax. You can read up on single file components here.

Download the following repository locally:

https://github.com/caseymorrisus/vue-button-tutorial

Once you have the project above cloned/checked out locally, head to the project root and use npm to install the project dependencies:

npm install

Tutorial

Now that everything is installed we should make sure everything works. From the root of your project, run:

npm run dev

This should start a development server at localhost:8080 which can be opened in your browser of choice. I prefer Google Chrome as it has a great extension, Vue.js devtools. If you open src/App.vue you will see that it currently only has a header component loaded in, that's no fun! Let's start off by defining a simple template for our Button component. Open src/components/Button/Button.vue and make the following changes:

Cool, pretty easy so far. Lets prepare the component to be imported and make sure the component loads without error before explaining it further. To do that, we need to talk a bit about application structure.

Application Structure

By default to import a component, you need to reference its URL relative to the current file. With a small application, this doesn’t seem like an issue, but can quickly get annoying in larger applications with more complex directory structures. To get around this issue, I setup a WebPack alias that points to our src/components directory. This allows us to ignore the relative location of the directory we are importing. I also go ahead and add an index.js file to each of our component directories to shorten our imports.

This would allows us to import components like so:

The WebPack alias I use to let me use Components is located in webpack.config.js and looks like:

You may be wondering why I give each component its own directory. I do this to give me a place to store files that are related to a component. These can be images used in a component, or child components that will only be used by a specific component. (E.g. Slider component has Slide components).

Button Content

The Button component still needs to be added to our view. Open App.vue and import it like so:

The component still needs to be locally registered before it can be used. Alter the components object for the App component to include the Button component:

We give our Button component a custom tag name of v-button so that it does not conflict with reserved HTML elements, as I did with the Header component as well. This is not necessary if the component name is not a reserved HTML element.

Finally, we can add the Button component to our template:

Doing this should add a button element to the page with text that says “Button”. The text content is coming from the fallback content defined within the Button component. Fallback content is defined by putting content between the <slot> tags for a component. More can be read about slots and fallback content here.

Let’s add our own custom content to the Button component:

This should change the content of the button from “Button” to “Custom”. You are not limited to strings/text content. Any content inserted in-between component tags will be inserted into the slot. For example, you could use an image icon rather than text like so (don’t actually add this):

Adding Interactivity/Events with Props

Alright, so far our Button component is pretty boring. At this point it is nothing more than a bloated implementation of a native HTML button. To make the Button component useful, we need to add the option to pass in a click event from the parent component. This is done through the use of props.

Open Button.vue , so far we've only altered the template. To allow our parent component to send a method to our Button component, we need to define an onClick prop:

In the above, we are giving our Button component a prop of onClick. We're telling Vue to validate the value passed in by using the type property and passing it the value of Function. This will cause Vue to throw a useful error in your development environment if a value of a different type is given. We are also telling Vue that this prop should always exist using required as a button component without a click event is fairly useless. You can read more about prop validation and defaults here.

Bind click event to the DOM

Our component still doesn’t react to user interaction, we need to bind the onClick method that is passed in as a prop. To do this, we will use v-on (more info) to bind the event to the desired DOM element. We will use the shorthand @click which is the same as typing v-bind:click which can be read about here.

If you try to click the button at this point nothing will happen. This is because we haven’t passed in a value for the onClick prop.

Passing a method from parent to child component

Open the App component located at src/App.vue and create a consoleClick method that logs a string to the console (more info on methods):

With the consoleClick method created within our App component, it is now ready to be passed in as a value for the onClick prop for the Button component. This can be done with the following:

The key here is :onClick which is the equivalent to v-bind:onClick (shorthand) which allows us to bind a JavaScript expression to our onClick prop. In this case we are passing in a function (and checking using validation!), but it can just as easily be a number, string, array, boolean, or object.

If you click on the button and look at your console, you should see the string Button clicked has been logged. Awesome, we've successfully passed a method from a parent component down to a child component and deferred calling that method until the child component has been clicked.

Multiple instances of a component

Components aren’t much fun if they’re only used once, let’s create another instance of our new Button component. Let’s also pass in a different method to the new Button instance. First, let’s add the new method to our App component, alertClick, which will create an alert when the Button is clicked.

Add another Button component directly after the first, giving it new slot content. Let’s also alter the slot content of the original button to match its behavior.

Both buttons should work, the first logging a message to your development console, the second, alerting the same message. Easy!

Free Functionality

Since we used a native button element as the root element of our Button component, we get some free functionality. If we had used a div as a root element, the following would not work. Using a native button element also has the added benefit of being semantically correct (more info). Edit the template for the App component to pass in a disabled prop to one of the buttons.

We can use shorthand syntax when passing a true value for a prop that expects a boolean. Passing disabled to our component is the same as passing :disabled="true". Notice we are using the v-bind: shorthand syntax to send in the value of true. Without it, Vue will think you are sending a string with the value of true aka "true". This is fine until you try to send in disabled="false" which will disable the button, because a string with the value of false is not a falsy value. It will return true.

Wrapping Up

We now have ourselves a nice, reusable Button component that could be extended further if we wanted to. It may seem like it took a lot of work to get here, but we covered a lot of important topics that you can build upon in the future. Look for more articles in the future, I plan on continuing the series to the point where we build a small UI framework together.

If you found anything useful in this article, it would mean a ton to me if you clicked the 💚 and shared with friends!

Creating Reusable Components with Vue.js : Button Component was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why?

I’m a developer at a digital design and technology studio called PHDL. One of our awesome clients is an experiential marketing firm based in San Francisco called Manifold. Like many companies, Slack has become instrumental to Manifold’s daily workflow, communication and culture; so much that they came to us with an idea: is it possible to allow anyone on their team to publish content from a Slack channel onto a section of their website in real time? We had previously built a carousel that updated for them in the “contact us” section of their website, but to update it required admin access and WordPress familiarity — any funny inspirations to put on the page usually died on the vine if the site admin wasn’t around, and so the idea was born. We would use Slack to allow anyone at Manifold to publish content to this page on their WordPress site.

After doing some initial research, I didn’t like similar implementations that already existed. I found them to be inflexible, and so I set out to create an easy and flexible solution that can fit into any system or framework. If you can open a socket connection and receive data via an API, this setup should work for you. Resources for: Slack, Node.js, Express, RethinkDB, Socket.io, Handlebars

The Flow

The Flow Expanded

• User sends message to specific Slack channel (e.g. #blog)
• Slack bot watches the #blog channel and receives the message
• Slack bot creates a RethinkDB entry based on message data
• Node server is connected to RethinkDB with a real-time change feed active (watches for changes, emits event and data)
• RethinkDB notifies Node server that data has changed and sends the data
• Node server emits ‘new post’ event with new data over Socket.io
• Node server serves Front End at “/”
• Client has an active Socket.io connection waiting for the Node server to emit events with data
• Client receives socket events and data, then updates the DOM accordingly

Three Distinct Parts

As you can see above, the application is split into three main parts:

1. Slack Bot

The Slack bot is a Node.js app that listens to a specific Slack channel (e.g #blog) and saves all data to a database using RethinkDB. It can be switched on and off by typing !on and !off commands in the chat.

2. Node Server

The Node server is an Express server that is connected to RethinkDB with a real-time change feed. When data is changed in the database, RethinkDB sends the data to the Node server through the change feed. When the Node server receives this data, it emits a socket event that the Client is connected to and waiting for. For added flexibility, the Node server also has an API endpoint to GET post data. This allows you to receive the posts without the need to connect to the database directly. This is useful for Front-End applications that cannot call a database.

3. Client

The Client is the end user. In this case, the Client is a website being served by Express at http://localhost:5000. When a user loads the website, a new Socket.io connection is established between the Client and the Node Server. Events and data are passed from the Node Server to the client in real-time. Past posts (prior to the user’s Socket.io connection) are rendered on load using Handlebars.

Now that we know a bit about the process, we can start coding.

Setup

Start off by cloning my sample repository using git:

git clone https://github.com/caseymorrisus/Slack-Live-Blog.git

You should see a file named server.js which contains the following:

Don’t worry about all of the dependencies for now, we will go over each part as we implement it.

Express Config

We will start off by adding the following Express configuration to the end of server.js:

Explanation

First, we tell Express to use Handlebars as its template engine.

We then set up the middleware and tell Express to serve static content from publicDir which was set to /public

After setting up the middleware, we can start the server.

Socket.io Server Config

Configuring the server to use Socket.io is fairly simple. All we are doing is opening a socket connection and logging to the server when a user connects and disconnects. This connection will be used later to emit events to the client.

Define Routes

Next to add into server.js are the two routes that will be served. The first route can be viewed at http://localhost:5000. It contains the following:

Route: “/”

Explanation

I won’t go into too much detail for the sake of brevity, however, I’ll continue to explain the most crucial pieces.

Below is how we set up a new route within Express. The following responds to GET requests at the route of “/”.

Connect to RethinkDB with the host “localhost” and the port “28015”. If you are hosting your database on a different server, replace localhost with the IP of that server.

Get the five most recent entries in the “posts” table.

Finally, we render the “home” view (home.handlebars) when the route is connected to. Send JSON object with 5 most recent entries to be rendered.

Route: “/posts”

Finally, we create a route which responds with a JSON object at http://localhost:5000/posts. This object contains the twenty-five most recent entries in the “posts” table within RethinkDB. While this functionality is not used for this specific implementation, it is a nice feature to have. Having this API allows the posts to be pulled safely from the database. This is useful for Front-End applications that don’t have the ability to connect to a database. Anything that can call an API now has access to your data!

RethinkDB Real-Time Change Feed

Finally, the last thing we add to server.js is the code needed to set up a real-time change feed for RethinkDB:

To explain further, the code below is for the change feed. We tell RethinkDB that we want to watch for changes in the ‘posts’ table. Whenever an entry is changed, it is sent to the Node server via the change feed. When the Node server receives changed data from RethinkDB, it sends that data to the Front-End (client) through an open socket connection and event ‘new post’.

The View

On the Front-End, we will be using Handlebars as our template engine. The data we are sending from Express is handled within views/home.handlebars. This file is inserted into views/layouts/main.handlebars where it says {{{body}}}. Anything you want to know about Handlebars can be found within their documentation.

Client Socket.io Configuration

Open public/js/production.js and you will find the following:

The majority of this file deals with DOM manipulations and animations within jQuery. That is not the focus of the article so I will continue to the important parts.

In the entire file, these two lines are the most important:

First, we open a socket connection with our Node server. Second, we wait for the Node server to emit a ‘new post’ event. Third, the Node server emits an event when the database has changed. A JSON object is passed along to the client through the ‘new post’ event. How you handle this data is up to you. In this case, I’m simply appending them to the DOM and keeping a maximum of five posts at any one time.

I thought you said something about a bot?

Start off by opening bot.coffee, as you can probably guess, we’ll be using CoffeeScript from now on. Once you open up the file, you should see a list of dependencies.

Each code snippet from here on should be appended to bot.coffee. Next, we configure Slack. You will need to visit the URL in the snippet to generate a bot and Slack Token.

Slack Bot Configuration

Next, we setup a simple object to store the bot’s options. For now, we are only using one option but this can be extended later.

Now, we will create a few helper functions to be used at a later time. Everything below is explained within the comments. If you want to use a different channel name, change ‘blog’ to the name of your desired channel.

Due to the significance of indentation within CoffeeScript, I’ve included the rest of the file in a single gist. Again, everything is explained in the code’s comments.

If you’d like to see the entire bot.coffee file you can find it here.

Starting The Server

We now have everything we need. You can start the Node server and bot in one command by entering npm start in the command line at document root. The page served at http://localhost.com will update in realtime when you post to Slack.

Wrapping Up

As you can see, it’s fairly easy to get something simple set up. The bot is looking a bit bare, but you can always add more features as they are needed. Some ideas for features and commands include:

• Admin permissions (only admins can use the bot)
• Update posts using the bot
• Delete posts using the bot
• Command to list most recent posts in Slack

Be warned, the code in this article was written as a prototype and proof of concept. It has since been refined, expanded upon, and changed for a production environment. If you use this in production, it is at your own risk. You can find examples in each resources documentation explaining what to do when deploying to production.