DEV Community: Sultan

Do or do not, there is no try

Sultan — Mon, 18 Dec 2023 19:19:20 +0000

The main building blocks of functional programming are pure functions. Side effects are their worst enemies because they make functions impure. For instance, JSON.parse meets nearly all the criteria for a pure function: it always produces the same output for the same input, and it does not depend on the global context or attempt to change it. However, it still harbors a side effect. When an invalid JSON is applied, the function not only fails to return a result but also breaks the application.

const bob = JSON.parse('{"name": "Bob"}') // -> Bob
const jackson = JSON.parse('Beat me, hate me') // -> 💥Error!

This behavior is by design, and to handle this issue, we need to wrap the function call in a try/catch block.

let jackson 
try {
  jackson = JSON.parse('You can never break me')
}
catch(error) {
  jackson = 'n/a'
}

We had to slightly increase the code and use a mutable variable. Using let is not that desirable, as this would require a more careful analysis of the code to track all the places where the variable can be changed, especially when dealing with larger codebases.

I would like to find a more elegant solution to this problem. As an idea, we can try adding an onError method to achieve a one-line solution:

const jackson = JSON.parse('Beat me, hate me').onError(() => 'n/a')

It looks nice, but extending objects or functions through prototypes is playing with fire. Moreover, it's not universally applicable. Every time we need to handle an exception, we first have to modify the original function and then call it. Doesn't sound that great, does it? But what if we create a wrapper function that temporarily extends any function with an onError method, without modifying it? In other words, the wrapper function will loan its methods to the wrapped functions, and once the execution is complete, the methods will be returned back to the owner. But don't worry, this will be an interest-free loan, so you won’t have to pay a dime!

const jackson = trap(JSON.parse('Beat me...')).onError(() => 'n/a')

To make usage even more convenient, we can add pipeline support for function composition, as follows:

const userName = trap('You can never break me')
  .then(JSON.parse)
  .then(user => user.name)
  .onError(() => 'n/a')
  .finally()

It closely mirrors Promise, with the only difference being the onError and catch methods. Essentially, we can use Promise directly without any additional wrapping functions.

const parseName = str => Promise.resolve(str)
  .then(JSON.parse)
  .then(user => user.name)
  .then(str => str.trim())
  .then(str => str.toUpperCase())
  .catch(() => 'n/a')
  .finally()

const bob = await parseName('{"name": " Bob  "}') // -> 'BOB'
const sam = await parseName('{"nick": " Sam  "}') // -> 'n/a'
const one = await parseName('{"name": 1}') // -> 'n/a'
const jackson = await parseName('You can never break me') // 'n/a'

The sequence of then and catch functions provides clear control flow and error handling. However, there is a small problem: the parseName function is now asynchronous, so the value assignment won't happen immediately after the function execution, but rather on the next event loop tick. This is not what we want. Luckily, we can create a function with the same interfaces as Promise, but it will work synchronously.

const flow = x => ({
  then: f => trapError(() => f(x)),
  catch: () => flow(x),
  finally: (f = x => x) => f(x),
})

const fail = x => ({
  then: f => fail(x),
  catch: f => trapError(() => f(x)),
  finally: () => {throw x},
})

function trapError(f) {
  try {
    return flow(f())
  }
  catch (error) {
    return fail(error)
  }
}

Below is an example of usage. In order to break chaining and get the value, we should call the finally method.

const findUser = id => flow(localStorage.getItem('users'))
  .then(JSON.parse)
  .then(users => users.find(user => user.id === id))
  .then(user => user.name)
  .catch(() => 'n/a')
  .then(str => str.toUpperCase())
  .finally() // 👈 stop chaining and get value

const bob = findUser(12)

Interesting fact: if you call the flow function with await, it may execute without invoking finally, even if the function is synchronous.

const ten = flow(7).then(x => x + 3).finally() // -> 10
const two = await flow(1).then(x => x + 1) // -> 2

Our function looks and behaves like an asynchronous function, but it does not actually support asynchronous code. This can be misleading. To avoid confusion, I suggest adding support for asynchronicity in the following way:

const isPromise = x => x instanceof Promise

const future = p => ({
  then: f => future(p.then(f)),
  catch: f => future(p.catch(f)),
  finally: (f = x => x) => p.then(f),
})

const flow = x => isPromise(x) ? future(x) : ({
  then: f => trapError(() => f(x)),
  catch: () => flow(x),
  finally: (f = x => x) => f(x),
})

Now, we can seamlessly mix asynchronous functions in our pipeline without concerns about distinguishing between synchronous and asynchronous code.

const refreshToken = salt => flow(localStorage.getItem('app'))
  .then(JSON.parse)
  .then(data => data.session.refreshToken)
  .then(saltedToken => atob(saltedToken).replace(salt, ''))
  .then(token => fetch(`/api/refresh-token/${token}`)) // 👈 now it is async fn
  .then(res => res.json())
  .then(json => json.token)
  .catch(() => window.location.href = '/login')

const token = await refreshToken('Never store token in the local storage!')

Functors and Monads

Without realizing it, we have gradually started using functors in our examples. It might come as a surprise, but the functions future, flow, and fail are actually functors. A functor acts like a container that holds a value, and we can access and potentially modify this value using the function provided to the then/catch methods. The functor flow recursively calls itself with a new value, allowing us to create endless chains of then/catch and build function compositions. Each then/catch is enclosed within a try/catch, ensuring safe function execution and managing two pathways: a successful path (then) and an error-handling path (catch). To retrieve the final value, we need to invoke the finally function, which ends the then/catch chain and delivers the result. An interesting feature of the finally function is that it can take another function for one last transformation before concluding.

const greet = flow('bob')
  .then(str => str.toUpperCase())
  .then(str => 'Hello '.concat(str))
  .finally(str => str.concat('!'))

console.log(greet) // -> Hello BOB!

Seems like everything is great, but there is still one thing. If we pass another flow into our pipeline, we will get a functor instead of a result value.

// welcome without finally
const welcome = name => flow(name)
  .then(str => str.toUpperCase())
  .then(str => 'Hello '.concat(str))
  .catch(() => 'Oops')

flow('{"name": "Bob"}')
  .then(JSON.parse)
  .then(user => user.name)
  .then(welcome) // 👈 nesting another flow will break 👇
  .finally(console.log) // -> {then: ƒ, catch: ƒ, finally: ƒ}

To unfold nested functors, the following changes need to be made:

const isFunctor = x => x?.finally instanceof Function

const flow = x => {
  if (isPromise(x)) return future(x)
  if (isFunctor(x)) return x
  return {
    then: f => trapError(() => f(x)),
    catch: () => flow(x),
    finally: (f = x => x) => f(x),
  }
}

const fail = x => ({
  then: (f, r) => r?.(x) ?? fail(x), // 👈 handle fail in promise
  catch: f => trapError(() => f(x)),
  finally: () => {throw x},
})

These changes make flow a monad. Although it may not be the ideal monad, it possesses some key properties of a monad. This allows us to nest other flows or functors within it.

flow('{"name": "Bob"}')
  .then(JSON.parse)
  .then(user => user.name)
  .catch(() => 'guest')
  .then(welcome) // 👈 nesting another flow
  .then(str => str.concat('!'))
  .finally(console.log) // -> Hello BOB!

In practice, you most likely don't need to use monads in their pure form. Instead, you will often use them inside functions that return values from the monad. However, there are cases when nesting functors/monads inside then/catch methods is reasonable. With the fail functor, we can interrupt the execution flow without throwing an exception. It is worth noting that throwing an exception can be a more costly operation compared to a regular function call.

const findUser = id => flow(localStorage.getItem('users'))
  .then(JSON.parse)
  .then(users => users.find(user => user.id === id))
  .then(user => user || fail('User not found')) // 👈 jump to the next catch on null
  .then(user => user.name)
  .catch(() => 'n/a')
  .then(str => str.toUpperCase())
  .finally()

const bob = findUser(12)

Another example is the halt functor, which can be used to skip all chains with a given value. This provides an easy way to end the entire pipeline.

const halt = x => ({
  then: () => halt(x),
  catch: () => halt(x),
  finally: (f = x => x) => f(x),
})

const findUser = id => flow(localStorage.getItem('users'))
  .then(JSON.parse)
  .then(users => users.find(user => user.id === id))
  .then(user => user || halt('N/A')) // 👈 quit with value
  .then(user => user.name)
  .then(str => str.toUpperCase())
  .finally()

Conclusion

Is this solution a complete replacement for try/catch? I would say that, no, it is not a replacement, but rather a powerful addition for managing code execution and error handling. This approach is convenient in cases where a function can continue its execution despite an error occurring. Additionally, this design pattern can be applied not only for error catching but also for other purposes. Here are some possible applications:

const Component = select(role)
  .when('admin', AdminView)
  .when('editor', EditorView)
  .when('user', UserView)
  .otherwise(GuestView)

const selectGrade = mark => select(mark)
  .when(val => val > 90, 'A'),
  .when(between(80, 89), 'B'),
  .when(between(70, 79), 'C'),
  .when(between(50, 69), 'D'),
  .otherwise('F')

const grade = selectGrade(78) // -> C

In this article, I intentionally did not follow the conventions and laws of monads. My objective was to introduce readers to an alternative approach to development while highlighting the beauty of monads, which is often hidden beneath academic terminology and excessive boilerplate code. Naturally, it is not possible to cover all possible aspects of this approach in a single article, but I hope that the information shared here will serve as a starting point for you to explore the world of monads.

P.S. You can find the online demo here 📺.

Simplified Redux

Sultan — Fri, 03 Nov 2023 13:49:00 +0000

In the previous article, Declarative JavaScript, we discussed how conditional flows can be represented as higher-order functions. In this chapter, we will continue to extend this concept to create Redux reducers. Despite its declining popularity, Redux can serve as a good example of how to reduce the boilerplate code around this library. Before proceeding, I highly recommend reading the first chapter.

Abstractions

You may have noticed that whenever you point at some object, if there is a dog alongside you, it will most likely just stare at your fingertip rather than the object itself. Dogs struggle to understand the abstract line between the finger and the intended object, because such a concept simply does not exist in their cognition. Fortunately, humans have this ability, and it allows us to simplify complex things and present them in a simple form.

In the diagram above, a blue square symbolizes an application, and a barrel attached to the box represents a database. Such diagrams help us understand complex architectural solutions without diving into the details of their implementation. The same method can be applied in programming by separating the main code from the secondary code by hiding them behind functions.

const initialState = {
  attempts: 0,
  isSigned: false,
}

// action payload 👇      👇 current state
const signIn = pincode => state => ({
  attempts: state.attempts + 1,
  isSigned: pincode === '2023',
})

const signOut = () => () => initialState

const authReducer = createReducer(
  initialState,
  on('SIGN_IN', signIn),
  on('SIGN_OUT', signOut),
  on('SIGN_OUT', clearCookies),
)

The input of the createReducer function is like the table of contents for a book. It allows us to quickly finding the necessary function based on the action type. Both signIn and signOut functions update the state object, accepting the action payload and the current state as input. The rest of the code, which involves the action type check and the reducer call, is encapsulated within the createReducer and on functions.

const createReducer = (initialState, ...fns) => (state, action) => (
  fns.reduce(
    (nextState, fn) => fn(nextState, action),
    state || initialState,
  )
)

const on = (actionType, reducer) => (state, action) => (
  action.type === actionType
    ? reducer(action.payload)(state)
    : state
)

For enhanced utility, we introduce the helper functions useAction and useStore:

import {useState} from 'react'
import {useDispatch, useSelector} from 'react-redux'

const useAction = type => {
  const dispatch = useDispatch()
  return payload => dispatch({type, payload})
}

const useStore = path => (
  useSelector(state => state[path])
)

const SignIn = () => {
  const [pincode, setPincode] = useState('')
  const signIn = useAction('SIGN_IN')
  const attempts = useStore('attempts')

  return (
    <form>
      <h1>You have {3 - attempts} attempts!</h1>
      <input
        value={pincode}
        onChange={event => setPin(event.target.value)}
      />
      <button
        disabled={attempts >= 3}
        onClick={() => signIn(pincode)}>
        Sign In
      </button>
    </form>
  )
}

Lenses

In functional programming, lenses are abstractions that make operations easier with nested data structures, such as objects or arrays. In other words, they are immutable setters and getters. They are called lenses because they allow us to focus on a specific part of an object.

First, let's see how to update a value without using lenses:

const initialState = {
  lastUpdate: new Date(),
  user: {
    firstname: 'Peter',
    lastname: 'Griffin',
    phoneNumbers: ['+19738720421'],
    address: {
      street: '31 Spooner',
      zip: '00093',
      city: 'Quahog',
      state: 'Rhode Island',
    }
  }
}

const updateCity = name => state => ({
  ...state,
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city: name,
    }
  }
})

const userReducer = createReducer(
  initialState,
  on('UPDATE_CITY', updateCity),
  ...
)

That’s pretty ugly, right? Now let's use the set/get lenses:

const updateCity = name => state => (
  set('user.address.city', name, state)
)

const updateHomePhone = value => state => (
  set('user.phoneNumbers.0', value, state)
)

const useStore = path => useSelector(get(path))
// or by composing
const useStore = compose(useSelector, get)

const homePhone = useStore('user.phoneNumbers.0')

Below is an implementation of the lenses. I should note that all of these functions are already available in the Ramda library.

const update = (keys, fn, obj) => {
  const [key, ...rest] = keys
  if (keys.length === 1) {
    return Array.isArray(obj)
      ? obj.map((v, i) => i.toString() === key ? fn(v) : v)
      : {...obj, [key]: fn(obj[key])}
  }

  return Array.isArray(obj)
    ? obj.map((v, i) => i.toString() === key ? update(rest, fn, v) : v)
    : {...obj, [key]: update(rest, fn, obj[key])}
}

const get = value => obj => (
  value
    .split(`.`)
    .reduce((acc, key) => acc?.[key], obj)
)

const set = (path, fn, object) => (
  update(
    path.split('.'),
    typeof fn === 'function' ? fn : () => fn,
    object,
  )
)

const compose = (...fns) => (...args) => (
  fns.reduceRight(
    (x, fn, index) => index === fns.length - 1 ? fn(...x) : fn(x),
    args
  )
)

Curring functions

A curried function can be referred to as a function factory. We can assemble a function from different places, or we can use them in composition with other functions. This is a truly powerful feature. However, when we call a curried function with all parameters at once, it may look clumsy. For instance, the call of the curried version of set would look like this:

set('user.address.city')(name)(state)

Let's introduce a curry function. This function converts any given function into a curried one, and it can be invoked in various ways:

set('user.address.city', 'Harrisburg', state) // f(x, y, z)
set('user.address.city', 'Harrisburg')(state) // f(x, y)(z)
set('user.address.city')('Harrisburg', state) // f(x)(y, z)
set('user.address.city')('Harrisburg')(state) // f(x)(y)(z)

Quite simple implementation and usage:

const curry = fn => (...args) => (
  args.length >= fn.length
    ? fn(...args)
    : curry(fn.bind(undefined, ...args))
)

const set = curry((path, fn, object) =>
  update(
    path.split('.'),
    typeof fn === 'function' ? fn : () => fn,
    object,
  )
)

const get = curry((value, obj) =>
  value
    .split(`.`)
    .reduce((acc, key) => acc?.[key], obj)
)

I often notice that many developers, for whatever reason, wrap callback functions in anonymous functions just to pass a parameter.

fetch('api/users')
  .then(res => res.json())
  .then(data => setUsers(data)) // 👈 no need to wrap
  .catch(error => console.log(error))   // 👈 no need to wrap

Instead, we can pass the function as a parameter. We should remember that the then function expects a callback function with two parameters. Therefore, direct passing will be safe only if setUsers expects only one parameter.

fetch('api/users')
  .then(res => res.json())
  .then(setUsers)
  .catch(console.log)

This reminds me of simplifying fractions or equations in basic algebra.

\newline (2x - 1)\cancel{(x + 2)} = 3\cancel{(x + 2)} \newline 2x - 1 = 3

.then(data => setUsers(data))
// 👇 it equals 👆
.then(setUsers)

Let's simplify the updateCity function:

const updateCity = name => state => (
  set('user.address.city', name, state)
)
// 👇 it equals 👆
const updateCity = set('user.address.city')

Or, we can place it directly in the reducer without declaring a variable.

const userReducer = createReducer(
  initialState,
  on('UPDATE_CITY', set('user.address.city')),
  on('UPDATE_HOME_PHONE', set('user.phones.0')),
  ...
)

The most important aspect is that we can now compose the set function and perform multiple updates at once.

const signIn = pincode => state => ({
  attempts: state.attempts + 1
  isSigned: pincode === '2023',
})

// 'state => ({ ...' is 👇 removed
const signIn = pincode => compose(
  set('attempts', attempts => attempts + 1),
  set('isSigned', pincode === '2023'),
)

const updateCity = name => state => ({
  lastUpdate: new Date(),
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city: name,
    }
  }
})

// 👆 it equals 👇
const updateCity = name => compose(
  set('lastUpdate', new Date()),
  set('user.address.city', name),
)

This programming style is called point free and is widely used in functional programming.

This article ended up being a bit longer than I had initially planned, but I hope you’ve gained some new knowledge. In the next article, we will touch on the topic of the try/catch construct and as usual, here's a small teaser for the next post:

const result = trap(unstableCode)
  .pass(x => x * 2)
  .catch(() => 3)
  .release(x => x * 10)

P.S.
You can check out the online demo here 📺.

For a demo with TypeScript, visit this online demo 🍕.

Declarative JavaScript

Sultan — Mon, 23 Oct 2023 16:19:33 +0000

Dipping your toes into the world of functional programming can sometimes feel overwhelming. The transition from understanding its core concepts to actually applying them in real-world scenarios can be challenging. If you're familiar with some functional programming techniques but unsure when and how to use them, you're in the right place. In this article, we'll discuss some key concepts and their practical uses, and also explore how declarative programming is connected to functional programming.

Imagine writing JavaScript code without using variables, loops, or logical constructs.

This might sound bold, right? But how often do you find yourself writing code like this to toggle the visibility of a component in JSX?

<div>
  {hasComments ? <Comments/> : null}
</div>

We can rewrite it in a more declarative way:

<div>
  <Comments visible={hasComments}/>
</div>

As noted, this version is more declarative. Although we still use the conditional statement if internally, the goal is to abstract it from the main code.

const Comments = ({visible}) => {
  if (!visible) return null
  ...
}

The visible property prompts us to write code in a declarative manner, even though the component itself is partially implemented in an imperative style.

Let's take a look at the logical operator switch, which isn't just closely related to if, but is also a favorite among many developers:

const App = () => {
  const role = useUserRole()
  let Component
  switch(role) {
    case 'ADMIN': {
      Component = AdminView
      break
    }
    case 'EDITOR': {
      Component = EditorView
      break
    }
    case 'USER': {
      Component = UserView
      break
    }
    default: {
      Component = GuestView
      break
    }
  }

  return (
    <main>
      <NavBar/>
      <Component/>
    </main>
  )
}

Perhaps you’ve already guessed where I'm heading with this, especially since a similar approach is implemented in React Router.

const App = () => (
  <main>
    <NavBar/>
    <Switch test={useUserRole()}>
      <Case when='ADMIN' use={AdminView}/>
      <Case when='EDITOR' use={EditorView}/>
      <Case when='USER' use={UserView}/>
      <Otherwise use={GuestView}/>
    </Switch>
  </main>
)

Let’s consider this code from the perspective of functional programming, where HTML/JSX tags are treated as functions that produce HTML output and tag attributes act as function input parameters.

// it will return HTML: <main id="app">Hello World<main/>
main({id: 'app', children: 'Hello world!'})

// The second parameter can be used as a children attribute
main({id: 'app'}, 'Hello world!')

Drawing from the concept above, let's express the JSX code through function sets. It's pertinent to note that switch/case are reserved JavaScript keywords, so we'll add underscores:

const app = () => (
  main(
    navbar(),
    switch_({test: useUserRole()},
      case_({when: 'ADMIN', use: AdminView}),
      case_({when: 'EDITOR', use: EditorView}),
      case_({when: 'USER', use: UserView}),
      otherwise({use: GuestView}),
    )
  )
)

As you can see, declarative code doesn't always mean HTML or JSX. In JavaScript, we can use functions to represent the syntax of these languages. According to JS conventions, functions should represent actions and usually start with a verb, such as find or setTitle. However, in this case, functions can also represent an entity. For example, an SQL query can be written like this:

// a function composition
query(
  select('name', 'email', 'country'),
  from('users'),
  where({age: less(21)}),
  groupBy('country'),
)

// or as a chaining function like Promise
select('name', 'email', 'country')
  .from('users')
  .where({age: less(21)})
  .groupBy('country')

// SELECT name, email, country FROM users WHERE age < 21 GROUP BY country

This way, I want to draw a connection between declarative and functional programming. I believe that functional programming does not intentionally pursue declarativeness; rather, it is a result of extensively using functions. It's worth mentioning that functional programming is not solely about the DRY principle, which involves extracting repetitive code into separate functions. At its core, functional programming focuses on crafting universal functions that are both highly composable and versatile in application.

Now we can take another look at the switch/case and represent them as a plain function:

const selectComponent= ({test, cases, defaultValue}) => {
  const found = cases.find([value] => test === value)
  return found?.at(1) || defaultValue
}

const App = () => {
  const role = useUserRole()
  const Component = selectComponent({
    test: role,
    cases: [
      ['ADMIN', AdminView],
      ['EDITOR', EditorView],
      ['USER', UserView],
    ],
    defaultValue: GuestView,
  })

  return (
    <main>
      <NavBar/>
      <Component/>
    </main>
  )
}

The current implementation falls short in terms of flexibility and composability with other functions. To enhance its utility, we could transform the selectComponent function into a higher-order function and break it down into more granular functions.

const select = (...fns) => value => fns.reduce(
  (found, fn) => found || fn(value), null
)

const when = (test, wanted) => value => {
  const matched = typeof test === 'function' ? test(value) : test === value
  return matched && wanted
}

const selectComponent = select(
  when('ADMIN', AdminView),
  when('EDITOR', EditorView),
  when('USER', UserView),
  () => GuestView,
)

const Component = selectComponent('EDITOR') // -> EditorView

If you're only somewhat familiar with the concept of curried functions, this serves as a solid illustration of their practical use. While a curried function resembles a standard function, its execution can be postponed until all its parameters have been supplied. This capability not only facilitates function composition, but also renders the code more declarative and understandable.

We have the capability to craft various iterations of the when function, all the while ensuring that the primary select function remains intact and requires no alterations. Below is an example that demonstrates how to support lazy loading of components:

import {Suspense, lazy} from 'react'

const when = (test, path) => value => (
  test === value && lazy(() => import(path))
)

const selectComponent = select(
  when('ADMIN', './admin-view'),
  when('EDITOR', './editor-view'),
  when('USER', './user-view'),
  () => GuestView,
)

const App = () => {
  const role = useUserRole()
  const Component = selectComponent(role)

  return (
    <main>
      <NavBar/>
      <Suspense fallback={<div>Loading...</div>}>
        <Component/>
      </Suspense>
    </main>
  )
}

If we take a much closer look at the initial version of the selectComponent function, it becomes clear that it is not possible to extend its functionality without making changes. With this approach, we can break down the code into smaller functions, each with a specific task in mind. This improves the test coverage experience and minimizes the future changes impacting multiple sections of the code. If we ever need to expand the functionality, we can simply add a new function and integrate it with the existing functions rather than rewriting the main function each time.

const between = (min, max) => n => (
  min >= n && n <= max
)

// range of values
const toGrade = select(
  when(val => val > 90, 'A'),
  when(between(80, 89), 'B'),
  when(between(70, 79), 'C'),
  when(between(50, 69), 'D'),
  () => 'F',
)

const grade = toGrade(81) // -> 'B'

In the next post we’ll take a detailed look at this technique using the example of creating Redux reducers. We will learn how to replace the try/catch approach and continue the discussion on functional programming.

const authReducer = createReducer(
  initialState,
  on('SIGN_IN', signIn),
  on('SIGN_OUT', signOut),
  on('SIGN_OUT', clearCookies),
)