DEV Community: Emmanouil Liakos

Jest with TypeScript and aliased imports (custom paths)

Emmanouil Liakos — Tue, 07 Feb 2023 19:12:25 +0000

In this post we are going to setup jest for a TypeScript project with custom aliases (path mapping) support. If you haven't read my previous post about cleaner imports in TypeScript using aliases, you can do that here. It's pretty cool that we can use the same aliases in our tests to keep them nice and clean ✨

We are going to use yarn package manager. However, there are no differences with npm - other than the commands themselves.

Install Jest

Run yarn add --dev jest.

Add TS support

Add type support: yarn add --dev @types/jest
Install ts-jest. It's a custom jest transformer that will help us use Jest with TypeScript.
Run yarn jest --init to initialize a config file. Answer the questions as you wish (ask Yes for TS support).
Go to your tsconfig and "@types/jest" inside types array:

{
...,
"types": [..., "@types/jest"],
...
}

Add path support

Make sure you have at least the following config in jest.config.ts:

import { pathsToModuleNameMapper, JestConfigWithTsJest } from "ts-jest";
import { compilerOptions } from "./tsconfig.paths.json";

const jestConfig: JestConfigWithTsJest = {
  preset: "ts-jest",
  moduleDirectories: ["node_modules", "<rootDir>"],
  moduleNameMapper: pathsToModuleNameMapper(compilerOptions.paths)
 }

export default jestConfig;

Here we import our custom paths defined in tsconfig.paths.json (for more info on this read here):

import { compilerOptions } from "./tsconfig.paths.json";

The moduleDirectories prop did the trick for me. Also make sure to remove comments from both jest.config and tsconfig, since they sometimes cause parsing errors. Hope this helped someone 😎

Cleaner imports with aliases in react and typescript ✨✨

Emmanouil Liakos — Sun, 03 Jul 2022 13:14:40 +0000

The problem with relative imports

As a project's been growing, you might've found yourself making imports like this:

import { someUtil } from '../../../../src/utils';
import defaultExport, { SomeModule } from '../../../src/modules/dummy-module';

This can quickly get out of hand, resulting in many chaotic imports from some deeply nested folders. This would get a lot cleaner, if we could do something like this:

import { someUtil } from '@/utils';
import defaultExport, { SomeModule } from '@dummy-module';

We essentially mapped @ to src folder and @dummy-module to src/modules/dummy-module folder which allowed us to reference them directly using their alias.

Configuring aliased imports

TypeScript configuration

In order for TypeScript to become aware of our alias paths, we must define them inside our tsconfig.json file, under compilerOptions:

// tsconfig.json

{
  "compilerOptions": {
    "baseUrl": ".",
    ...,
    "paths": {
      "@/*": ["src/*"], // 👈 This line allows us to import from folders inside "src" folder using "@"
      "@dummy-module": ["src/modules/dummy-module"], // 👈 This line allows us to import from the "dummy-module" folder itself using "@dummy-module"
      "@dummy-module/*": ["src/modules/dummy-module/*"] // 👈 This line allows us to import from folders inside "src/modules/dummy-module" folder using "@dummy-module"
    }
  },
    ...
}

We are now able to import using the above aliases. In case TypeScript still complains about your imports, then create a separate tsconfig.paths.json file next to tsconfig.json (inside root directory), to extend your base config from:

// tsconfig.paths.json

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"], // 👈 This line allows us to import from folders inside "src" folder using "@"
      "@dummy-module": ["src/modules/dummy-module"], // 👈 This line allows us to import from the "dummy-module" folder itself using "@dummy-module"
      "@dummy-module/*": ["src/modules/dummy-module/*"] // 👈 This line allows us to import from folders inside "src/modules/dummy-module" folder using "@dummy-module"
    }
  }
}

and modify tsconfig.json like this:

// tsconfig.json

{
  "compilerOptions": {
    "baseUrl": ".",
    ... 👈 Remove "paths" option
  },

  "extends": "./tsconfig.paths.json" // 👈 Add this line
}

Webpack configuration

In a react app, you've most likely used create-react-app as a scaffold. So you need to override its internal webpack configuration, in order to let the bundler know how to resolve your aliases during build time. To do that without ejecting, you can use craco:

npm i @craco/craco

yarn add @craco/craco

Next, create a craco.config.js file at your project’s root and paste this code:

const path = require('path');

module.exports = {
  webpack: {
    alias: {
      '@': path.resolve(__dirname, 'src'),
      '@dummy-module': path.resolve(__dirname, 'src/modules/dummy-module'),

    },
  },
};

Finally, replace react-scripts with craco inside package.json file:

"scripts": {
    "start": "craco start",
    "build": "craco build",
    "test": "craco test",
    "eject": "craco eject"
 }

and restart your app:

yarn start

And that's all folks 🥳

How to handle boolean values in SQLite using JavaScript Proxies

Emmanouil Liakos — Tue, 22 Mar 2022 19:30:53 +0000

The problem with Booleans in SQLite

If you've ever worked with SQLite, you should be aware of the supported data types and Boolean isn't one of them. More specifically as stated here:

2.1. Boolean Datatype

SQLite does not have a separate Boolean storage class. Instead, Boolean values are stored as integers 0 (false) and 1 (true).

SQLite recognizes the keywords "TRUE" and "FALSE", as of version 3.23.0 (2018-04-02) but those keywords are really just alternative spellings for the integer literals 1 and 0 respectively.

Most JavaScript libraries for SQLite3 don't support TRUE and FALSE keywords and they require you to prepare the statements in your code using integers. For example, in better-sqlite3 you would have to do this:

const payload = {
  isActive: 1, // <======
  username: 'Brad',
  password: '1234',
  email: 'brad@gmail.com',
};

const result = database
  .prepare(
    `INSERT INTO accounts(isActive, username, password, email) VALUES(@isActive, @username, @password, @email) `
  )
  .run({ bucketID, taskSiteID, name, username, password, email }).changes;

Using number instead of boolean across your entire app would make for a terrible developer experience (plus probably use more memory).

You could use a helper function to transform your payload objects' boolean properties to numbers (I had actually done this once, in the past), but then you'd have to manually run it before every query. Yikes. Wouldn't it be great if this logic was executed in the background, every time we prepared and ran a statement?

Welcome ES6 Proxies 👋

One of the newer JavaScript features is the Proxy object. Proxies are essentially "traps" that intercept object operations like getters, setters and function calls. Using Proxies we can modify the SQLite JS wrapper library to execute our own logic, kind of like a middleware.

Writing the helper function

For ease of development, we are going to use mapValues & isPlainObject utility functions from lodash , but you can of course code your own. The function below will map through an object (one-level deep) and convert values of type boolean to type number.

import { mapValues } from 'lodash';

const booleanEntriesToNumbers = (object) =>
  mapValues(object, (value) =>
    typeof value === 'boolean' ? Number(value) : value
  );

Using proxies to intercept query calls

Below we import better-sqlite3 library and create a new database instance. Afterwards, we override the default prepare method with our own, which in turn overrides the methods run, get and all, by creating a new proxy for each one. You can of course create a proxy for any other method you want.

import Database from 'better-sqlite3';

// Create new database instance
const db = new Database(dbFilePath);

// We will use this function to override the default "prepare" method
const proxiedPrepare = new Proxy(db.prepare, {
    apply: (prepare, prepareThisArg, [stringStatement]) => {
      const statement = prepare.call(prepareThisArg, stringStatement);

      // Override the default "run" method
      statement.run = new Proxy(statement.run, {
        apply: (run, runThisArg, args) => {
          const mappedArgs = args.map((arg) =>
            isPlainObject(arg) ? booleanEntriesToNumbers(arg) : arg
          );

          return run.call(runThisArg, ...mappedArgs);
        },
      });

      // Override the default "get" method
      statement.get = new Proxy(statement.get, {
        apply: (get, getThisArg, args) => {
          const mappedArgs = args.map((arg) =>
            isPlainObject(arg) ? booleanEntriesToNumbers(arg) : arg
          );

          return get.call(getThisArg, ...mappedArgs);
        },
      });

      // Override the default "all" method
      statement.all = new Proxy(statement.all, {
        apply: (all, allThisArg, args) => {
          const mappedArgs = args.map((arg) =>
            isPlainObject(arg) ? booleanEntriesToNumbers(arg) : arg
          );

          return all.call(allThisArg, ...mappedArgs);
        },
      });

      return statement;
    },
  });

// Override the default "prepare" method
db.prepare = proxiedPrepare;

Essentially, once a call to the prepare method is triggered, we tell JavaScript: Wait! We want to modify this function call. Instead of executing the logic that the original developer intended, we instead want to execute our own logic first (which is the mapping of the object payload). After executing our own logic, we return the result of calling the original method by using call to bind the this argument. If you want to read more about how proxies work, read here. For our implementation we used the apply method here.

Thanks for reading this post, I hope it helped someone working with SQLite in JavaScript 👊

Conditional GitHub action based on commit message

Emmanouil Liakos — Mon, 01 Nov 2021 14:39:42 +0000

It's really annoying having a certain build/deployment GitHub action run on every push.

You can use this to run it based on the commit message's content:

name: Publish

on:
  push:
    branches:
      - master

jobs:
  publish:
    if: "contains(github.event.head_commit.message, '[build]')"

Feel free to change the '[build]' part with whatever string you want.

You can also put a ! at the beginning to invert the logic (Run the action on commit messages that DON'T contain a certain string)

Real-time app using React, Redux, Tailwind CSS & Firebase - Part 3

Emmanouil Liakos — Wed, 27 Oct 2021 16:13:25 +0000

1. Setting up
2. Creating Heading component
3. Creating UserName component
- Crafting the state
  - Constants
  - Actions
  - Reducers
4. Adding Firebase persistence
- Push updates to Firebase
- Receive updates from Firebase

NOTE: This series goes a bit unconventional, by not using any libraries or abstractions for Redux, following plain Flux architecture conventions. The recommended way of writing Redux is by using RTK (Redux Toolkit).

Previously in part 2, we did all the hard work of setting up Redux & Firebase, plus creating and connecting our first component. In this part, we are going to add the initial user functionality by assigning a default, random username when first visiting the app and also being able to edit it.

As per the requirements laid out in the first part:

Each client gets assigned a default random username when first visiting the app which he can also refresh.
Any participant can edit his/her username, as well as the feature-to-be-implemented title.

So, let's go and see what we can do! 🚀🚀

Setting up

The Heading component is going to host the application title, as well as the UserName component itself. Inside the components folder create a Heading folder and add two more things:

A UserName folder, which is going to hold the relevant component.
A Heading.js file.

A visual reminder of what we are building:

We are also going to create three utility functions to make local storage manipulation easier throughout the app. Inside the utils folder create three files named getLocalStorage.js, setLocalStorage.js and removeLocalStorage.js and paste the following functions, to each one respectively:

// getLocalStorage.js

const getLocalStorage = key => {
    return JSON.parse(localStorage.getItem(key));
};

export default getLocalStorage;

// setLocalStorage

const setLocalStorage = ({ key, value }) => {
    localStorage.setItem(key, JSON.stringify(value));
};

export default setLocalStorage;

// removeLocalStorage

const removeLocalStorage = key => {
    localStorage.removeItem(key);
};

export default removeLocalStorage;

Creating Heading component

Import our UserName component (which we are going to implement right after) and place it inside the Heading, along with a simple title for our app and some styles. Paste the following code inside the Heading.js file:

import UserName from "./UserName";

const Heading = () => {
    return (
        <div className="md:flex md:items-center md:justify-between">
            <div className="flex-1 min-w-0">
                <h2 className="text-2xl font-bold leading-7 text-gray-900 sm:text-3xl">
                    Scrum Voting App
                </h2>
            </div>
            <div className="mt-10 flex md:mt-0 md:ml-4 justify-center">
                <div>
                    <UserName />
                </div>
            </div>
        </div>
    );
};

export default Heading;

Creating UserName component

Under components/Heading/UserName create an index.js file and add the following code:

// Generic Input component we also used for FeatureTitle
import Input from "../../Input/Input"; 

import { useDispatch, useSelector } from "react-redux";
import { useEffect } from "react";

// Redux action/thunks
import updateUser from "../../../store/actions/users/updateUser";

// Simple utility to retrieve and parse values from local storage
import getLocalStorage from "../../../utils/getLocalStorage";
import createDefaultUser from "../../../common/createDefaultUser";

const UserName = () => {
    const dispatch = useDispatch();
    const state = useSelector(state => state.users);

    const currentUserId = getLocalStorage("userId");

  // Default user creation handling
    useEffect(() => {
        // Create a user if none exists
        if (currentUserId === null) createDefaultUser(dispatch);
    }, [dispatch, currentUserId]);

    // Retrieve current user using saved id from local storage
    const user = state.users.find(user => Object.keys(user)[0] === currentUserId);

    const handleUserUpdate = event => {
        // Action payload (updated user object)
        const updatedUser = {
            id: currentUserId,
            data: {
                ...user[currentUserId],
                username: event.target.value
            }
        };

        dispatch(updateUser(updatedUser));
    };

    return (
        <Input
            label="Username"
            placeholder="Type a username..."
            handleChange={event => handleUserUpdate(event)}
            // While loading display a loading message, else display current user
            value={user ? user[currentUserId].username : "Loading username..."}
            name="username"
            className="inline-flex items-center px-4 py-2 border border-transparent rounded-md shadow-sm text-sm font-medium focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500"
            // Disable editing while loading
            disabled={user ? false : true}
        />
    );
};

export default UserName;

I have placed some comments to make things easier to grasp. We basically add an Input component, which will a have a dual role: Displaying our current username and changing it.

Crafting the state

Let's go ahead and create anything state-related to add and update users.

Constants

Under store/constants create a file named users.js. It will contain all the action constants for the user slice.

For now, we only want ADD, UPDATE and REVERT functionality, so go ahead and add those three constants:

export const ADD_USER = "ADD_USER";
export const UPDATE_USER = "UPDATE_USER";
export const SET_USERS = "SET_USERS"; // This is going to be used for state reversion

Actions

Under store/actions create a folder named users. It will hold all user-related actions. First, we are going to create an action to add a user, so go ahead and create a file named addUser.js. Then paste the following code:

// Firebase module to add user
import firebaseAddUser from "../../../firebase/users/addUser";
import setLocalStorage from "../../../utils/setLocalStorage";

const addUser = payload => (dispatch, getState, getFirebase) => {
    // Get firebase object
    const firebase = getFirebase();
    const state = getState();

    // Username of the new user
    const { username: value } = payload;

    // Get old state (used to revert in case of error)
    const {
        users: { users: oldState }
    } = state;

    // Pass necessary data to our firebase module
    const config = {
        ref: "users/", // Firebase reference to perform query on
        payload,
        oldState,
        firebase,
        dispatch
    };

    // Update local storage with the username to create persistency
    setLocalStorage({ key: "username", value });

    // Add user to firebase
    firebaseAddUser(config);
};

export default addUser;

What we just created above is called a thunk which, as we stated here in the previous part, is basically an enhanced action which returns a function instead of an object. Inside this function we can run any asynchronous code we want, as well as dispatch other actions. Notice how dispatch, getState and getFirebase methods are provided as arguments to our action, by the thunk middleware.

Once again, I hope that the comments help explain what's going on above. We are doing two main things here:

Creating a config object to pass to firebaseAddUser (which is called asynchronously).
Persist username to local storage. This is going to be useful in getting the user identified correctly and not creating a new one, each time he visits the app on the same browser (provided he doesn't clear the local storage).

Also, notice how we are not dispatching any action to update the state. The reason is that there can be no change in the UI state (and thus a visual change), until we get a response from the database. It's also an automatic and one-time procedure, while the result is stored in local storage, so no Redux persistence is needed.

Similarly, let's create the action to update a user. Again, under the actions directory create a file named updateUser.js and paste the following code:

import { UPDATE_USER } from "../../constants/users";

// Firebase module to update user
import firebaseUpdateUser from "../../../firebase/users/updateUser";

const updateUser = ({ id, data }) => (dispatch, getState, getFirebase) => {
    const firebase = getFirebase();
    const state = getState();

    // Grab user object form state (used to revert in case of error)
    const [oldState] = state.users.users.filter(user => user[id]);

    const config = {
        ref: `users/${id}`, // Firebase reference to perform query on
        payload: data,
        oldState,
        firebase,
        dispatch,
        resetActionType: UPDATE_USER
    };

    // Update user record in firebase
    firebaseUpdateUser(config);

    // Dispatch asynchronously to maintain a responsive UI
    dispatch({
        type: UPDATE_USER,
        payload: {
            [id]: data
        }
    });
};

export default updateUser;

Some notes:

Regarding the ref property usage you can check the Firebase Documentation. Basically, it's a "path" used to specify the location in our database, upon which the query is going to execute.
Regarding the two custom firebase modules, firebaseAddUser and firebaseUpdateUser, we are going to create them right after finishing with the reducers below.
The reason why we are specifying the resetActionType is because later on, we are going to be using a different reducer when resetting the state, based on whether we are updating a single user or resetting the votes for every user.
In contrast to the addUser action, here we are dispatching an action to update the state which happens asynchronously and independently of the Firebase update, in order to maintain a responsive UI.

Reducers

Under store/reducers create a users.js file to create our users reducers. Then paste the following:

import * as actionTypes from "../constants/users";

const initState = {
    users: []
};

const usersReducer = (state = initState, action) => {
    switch (action.type) {
        case actionTypes.ADD_USER: {
            return {
                ...state,
                users: [...state.users, action.payload]
            };
        }

        case actionTypes.UPDATE_USER: {
            return {
                ...state,
                users: state.users.map(user => {
                    /*
                     * Grab IDs
                     */
                    const [stateUserId] = Object.keys(user);
                    const [payloadUserId] = Object.keys(action.payload);

                    // Return the same user object if IDs don't match
                    if (stateUserId !== payloadUserId) return user;

                    // Else replace objet and update user
                    return action.payload;
                })
            };
        }

        case actionTypes.SET_USERS:
            return {
                ...state,
                users: action.payload // Replace the whole users array
            };

        default:
            return state;
    }
};

export default usersReducer;

Don't forget to also combine the new reducer with the root one. Make sure that store/reducers/index.js looks like this:

import { combineReducers } from "redux";
import feature from "./feature";
import users from "./users"; // <-- New line

export default combineReducers({
    feature,
    users // <-- New line
});

Adding Firebase persistence

Push updates to Firebase

Now we have to persist our Redux data to Firebase, just as we did in the previous part for the FeatureTitle component. Under src/firebase create a users folder and add an addUser.js file. Then paste the following code:

import { SET_USERS } from "../../store/constants/users";

const addUser = ({ ref, payload, oldState, firebase, dispatch }) => {
    firebase
        .ref(ref) // Select ref to update
        .push(payload) // Push the new user

        // Handle error
        .catch(e => {
            // Revert to old state in case of error
            dispatch({
                type: SET_USERS,
                payload: oldState
            });

            /* 
            * Dispatch snackbar with our browser's
            * built-in, sophisticated notification system 😎
            */
            alert("There was an error performing the request.");
        });
};

export default addUser;

The above code will handle the persistence of any new user that gets added to the database. To persist any updates made, add the following action in a file named updateUser.js:

import debounce from "../../utils/debounce";

const updateUser = ({
    ref,
    payload,
    oldState,
    firebase,
    dispatch,
    resetActionType
}) => {
    firebase
        .ref(ref)
        .set(payload)
        .then(error => {
            // Revert to old state in case of error
            if (error) {
                dispatch({
                    type: resetActionType,
                    payload: oldState
                });

                /*
                 * Dispatch snackbar with our browser's
                 * built-in, sophisticated notification system 😎
                 */
                alert("There was an error performing the request.");
            }
        });
};

export default debounce(updateUser, 500);

The logic is very similar here, except that we are also debouncing the action, since it is subject to manual user typing and can very well be spammed.

Receive updates from Firebase

Same as with the FeatureTitle component from the previous part, we need to setup the appropriate listeners in order to successfully receive updates from Firebase and update our Redux store. Inside store/actions/users folder the we have created, add a new file named setupFirebaseListeners.js. The code inside this file is going to do exactly that: Setup the appropriate listeners in order to subscribe to updates from Firebase.

import { ADD_USER, UPDATE_USER } from "../../constants/users";

import getLocalStorage from "../../../utils/getLocalStorage";
import setLocalStorage from "../../../utils/setLocalStorage";

const setupUsersListener = () => (dispatch, getState, getFirebase) => {
    const firebase = getFirebase();
    const usersRef = firebase.database().ref("users");

    /* User updates handling */
    usersRef.on("child_changed", snapshot => {
        const { key } = snapshot;

        // Update state
        dispatch({
            type: UPDATE_USER,
            payload: {
                [key]: snapshot.val()
            }
        });
    });

    /* Users loading and new user handling */
    usersRef.on("child_added", snapshot => {
        const user = snapshot.val(); // get user object
        const { username } = user;
        const { key } = snapshot; // user ID

        if (username === getLocalStorage("username")) {
            // Save user id in local storage if it matches own username
            setLocalStorage({ key: "userId", value: key });
        }

        // Update state
        dispatch({
            type: ADD_USER,
            payload: {
                [key]: user
            }
        });
    });
};

export default setupUsersListener;

The thunk we created above is going to be dispatched once on application start and listeners for the relevant Firebase events are going to be registered. Import the action and dispatch it inside App.js:

import "./App.css";

import FeatureTitle from "../components/FeatureTitle";

import { useDispatch } from "react-redux";
import { useEffect } from "react";

import setupFeatureListeners from "../store/actions/feature/setupFirebaseListeners";
import setupUsersListeners from "../store/actions/users/setupFirebaseListeners"; // <--- New line

function App() {
    const dispatch = useDispatch();

    // Setting up listeners
    useEffect(() => {
        dispatch(setupUsersListeners()); // <--- New line
        dispatch(setupFeatureListeners());
    }, [dispatch]);

    return (
        <main className="max-w-7xl mx-auto my-5 px-4 sm:px-6 lg:px-8">
            <div className="flex flex-col flex-wrap max-w-3xl mx-auto mt-10">
                <div className="flex justify-center">
                    <FeatureTitle />
                </div>
            </div>
        </main>
    );
}

export default App;

That's it! Run npm start, visit localhost:3000 (or whatever port you are using) and you should be able to see a default username assigned on the top right corner. Try editing it on both your browser and firebase and make sure that the two are synced. If you try to open the app in Incognito mode, you are going to get assigned a new user, because of a clean local storage.

Thanks for reading, stay tuned for the next one 🎉🎉

Debug Electron production binaries on Windows, Mac & Linux

Emmanouil Liakos — Wed, 20 Oct 2021 09:49:20 +0000

In this short article, I would like to show you how to debug Electron production binaries on Windows, Mac & Linux.

Sometimes you might want to see the log output of a production binary built with Electron and for some reason the web resources on this subject are extremely limited, rendering this a non-trivial task.

Windows

If you are using Windows, it's pretty straightforward. Just provide the path of your executable with the --debug flag and it should do the trick.

& 'path/to/MyElectronApp.exe' --debug

Mac

For MacOS, it gets a bit more complicating - as is always the case with Apple 😀. You have to follow a different approach based on whether you have code-signed your application or not. Essentially, if the binary is code-signed with a certificate, then you have to strip it in order for the debugger to work.

In any case you have to use the lldb Debugger and your application's path (probably something like /Applications/MyElectronApp.app).

Unsigned binary

For an unsigned binary run:

  lldb /Applications/MyElectronApp.app

Once the target has been created, run run to open the app.

When you are finished, run exit to close the debugger.

Signed binary

The methodology for a signed binary is essentially the same, but requires an extra step before proceeding. If you try to debug a code-signed binary you will likely get the following error message:

error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries when the attached failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))

To bypass this, you have to strip the certificate using the following script:

#! /bin/bash
# Simple Utility Script for allowing debug of hardened macOS apps.
# This is useful mostly for plug-in developer that would like keep developing without turning SIP off.
# Credit for idea goes to (McMartin): https://forum.juce.com/t/apple-gatekeeper-notarised-distributables/29952/57?u=ttg
app_path=$1

if [ -z "$app_path" ];
then
    echo "You need to specify app to re-codesign!"
    exit 0
fi

# This uses local codesign. so it'll be valid ONLY on the machine you've re-signed with.
entitlements_plist=/tmp/debug_entitlements.plist
echo "Grabbing entitlements from app..."
codesign -d --entitlements :- "$app_path" >> $entitlements_plist || { exit 1; }
echo "Patch entitlements (if missing)..."
/usr/libexec/PlistBuddy -c "Add :com.apple.security.cs.disable-library-validation bool true" $entitlements_plist
/usr/libexec/PlistBuddy -c "Add :com.apple.security.cs.allow-unsigned-executable-memory bool true" $entitlements_plist
/usr/libexec/PlistBuddy -c "Add :com.apple.security.get-task-allow bool true" $entitlements_plist
echo "Re-applying entitlements (if missing)..."
codesign --force --options runtime --sign - --entitlements $entitlements_plist "$app_path" || { echo "codesign failed!"; }
echo "Removing temporary plist..."
rm $entitlements_plist

Save this in a file locally and run it, while also providing the application's path:

bash ~/path/to/script.sh ~/path/to/MyElectronApp.app

Finally you can run the debugger in the exact same way as with the unsigned binary (using the lldb command).

You can of course chain the commands to strip the certificate and run the app in one go:

bash ~/path/to/script.sh ~/path/to/MyElectronApp.app && lldb ~/path/to/MyElectronApp.app

Linux

This is the easiest of the three. Just open the app from a terminal and you shall see the output:

'path/to/my/ElectronApp.AppImage'

Note: I haven't tried it with any target other than AppImage, but I presume that it should work in the same way.

Hope this was useful, thanks for reading! 🤓

CRLF: Mind the line

Emmanouil Liakos — Sun, 20 Jun 2021 08:14:21 +0000

Introduction

Have you ever had an issue with line endings, because the file was created on another OS? I actually had line endings cause a weird and hard-to-troubleshoot bug in one of my dependencies that used txt files. No, I'm serious. I ended up using a HEX editor to keep my sanity from going bananas. That's what you could end up doing after a long and tiresome coding session, so go ahead and make yourself a favor by reading the rest of this post (jk) 🤣

In this article I am going to briefly discuss this problem, as well as why different operating systems sometimes use different line endings - DOS/Windows uses CR AND LF as EOL character, while UNIX uses only LF. Line endings, as any other character, are encoded in numbers which are in turn encoded in bytes. The ASCII character encoding standard is responsible for mapping those characters to numbers. Technically, CRLF is more accurate, but more on this later.

Line ending characters (EOL, CR and LF) are control characters, meaning that they are not visible. Their role is to inform the computer about certain actions and are of no visual value to the user. The fact that they are not visible can cause anger and frustration while observing two seemingly identical files which could have different line-endings. The only way you could tell the difference is to compare them byte-by-byte using a HEX editor. Finally, it is important to note that Git uses "native" as a default value for core.eol configuration which means that it will use whatever line-ending is specified by the OS.

`LF`: Line feed

LF stands for "Line Feed". The well-known newline escape sequence is \n. This control character indicates a new line and tells the computer to move the cursor one line below.

`CR`: Carriage Return

CR stands for "Carriage Return". The escape sequence is \r and it informs the computer to return to the beginning of the current line.

`CRLF`: Carriage Return - Line Feed

You might've guessed it by now: Combining those two characters would result in what one expects when pressing the "Enter" key in a word processor.

Return the cursor to the beginning of the line.
Move one line to the bottom.

That is actually how early typewriters worked.

The bug

The problem with line-endings is that, by default, Git WILL convert them to CRLF if using Windows and LF if using UNIX/OS X, no matter what. In case you haven't configured Git to handle line-endings in a certain way, pulling from a repo which doesn't have a .gitattributes file to enforce a specific EOL character is going to cause you headaches. That's exactly what I encountered when a dependency, which happened to be committed in a different OS, was reading txt files from the filesystem and splitting them by \n (LF). I was using a Windows machine, so Git was quietly converting them to CRLF (\r\n). Thus the application would produce weird bugs.

What was even more frustrating is that git-diff would not show any differences between the original files and my local copies. The files were seemingly identical! In the past, I had messed with line-endings, but not to this extent. Having a brain-fog due to long hours of coding, I decided to just open a HEX editor and inspect the bytes. Boom! I started to notice differences right away. So, I was at least sure that the files were indeed different. By taking a closer look, one could see that the bytes would differ after each word (it was a stopwords file, so there were many words separated by new lines). And that's the point when everything started to make sense.

The fix

After inspecting the original files' EOL which was LF, I immediately added a .gitattributes file enforcing LF line-endings on txt files:

* text=auto eol=lf

This rule is going utilize Git's filetype detection algorithm to resolve txt files and enforce LF line-endings on both checkout and commit.

Any file committed before the addition of the .gitattributes file, should be renormalized. This is done by running the following command:

git add --renormalize .

This command will update the line-endings in Git index, effectively staging the files for commit. Current working tree WILL NOT be updated- you have to re-fetch. To ensure that all files are using LF you can run:

git ls-files --eol

# This will print:
# i/lf    w/crlf  attr/text=auto eol=lf   file.txt
#
# Where:
# i = Index line-endings
# w = Working tree line-endings
# attr = Any .gitattributes rules that may apply

Some quick history

While researching the issue, I found some really interesting historical context which I really encourage you to read, in order to understand the topic more thoroughly.

As stated in the Introduction part of this post, EOL characters were inspired by early typewriters. Back in the day, when typing on such a machine, the typist needed to feed a paper sheet to the machine. On each keystroke the machine would print the letter onto the sheet and move the carriage so that the next letter would appear to the right of the previous one. Additionally, the carriage needed to be reset when inserting a new line. So, the process of writing into a new line involved resetting the carriage, as well as rotating it to move the sheet upwards. Resetting the carriage amounts to CR and rotating the carriage to LF. Who would've though, eh?

Now, regarding Windows vs UNIX (CRLF vs LF), it's obvious that, while redundant nowadays, CRLF represents the whole process of "inserting a new line", abiding to the original convention. To me, as long as everything is configured correctly, I don't really care at all 😅

References

Quick post about the SQLite UPSERT and the new RETURNING clause.

Emmanouil Liakos — Fri, 28 May 2021 16:59:49 +0000

The RETURNING clause

You can read the official docs here.

Many times we find ourselves wanting to return some data (probably the id) after inserting records in our database. Since version 3.35.0 (2021-03-12), SQLite supports the RETURNING clause, which allows you to return a result row (or specific columns) for each modified database row by a DELETE, UPDATE or INSERT statement.

INSERT INTO customers (fullName, birthdateTimestamp, address) 
VALUES ('Andrew Mitch', 643911868, '206 Grange Road, Gillingham') 
RETURNING *;

The above query, after execution, will return us every value inserted in the database, along with the id of each row. This way we can avoid making another SELECT query to the database. Pretty neat, eh?

The UPSERT clause

You can read the official docs here.

Another nice little feature is the UPSERT clause. This was added in version 3.24.0 (2018-06-04) and it causes INSERT to behave either like an UPDATE or a no-op, in case of a UNIQUE CONSTRAINT or a PRIMARY KEY CONSTRAINT violation.

To elaborate, let's suppose that you have an action_records table which holds all actions fired by users in the users table, for a specific session. When a new action is fired you want to either insert a new action_record with no error, or, if existing AND has the same session timestamp (this is handled by the ON CONFLICT clause), update the old one. You can also optionally add a WHERE statement which will result in a no-op, if not met. The query below should do it:

-- Create users table and assign userID and sessionStartTimestamp as a UNIQUE CONSTRAINT.
DROP TABLE IF EXISTS "action_records";
CREATE TABLE IF NOT EXISTS "action_records" (
    "id" INTEGER NOT NULL,
    "userID" INTEGER NOT NULL,
    "sessionStartTimestamp" INTEGER NOT NULL,
    "errorMsg" TEXT,
    PRIMARY KEY("id" AUTOINCREMENT),
    FOREIGN KEY("userID") REFERENCES "users"("id") ON DELETE CASCADE,
    UNIQUE(userID, sessionStartTimestamp)
);

-- Insert new record or update the old one based on UNIQUE_CONSTRAINT OF userID & session_start_timestamp
INSERT INTO action_records (userID, errorMsg, sessionStartTimestamp) 
VALUES (258, null, 643911868) 
ON CONFLICT(userID, sessionStartTimestamp) -- Conflict when a record for the same user and session exists
DO UPDATE SET errorMsg = 'An error occured'
WHERE errorMsg IS NOT NULL -- This will be a no-op in case there is already an error and you don't want to update it
RETURNING *; -- Optionally adding RETURNING to retrieve any number of columns we want

UPSERT & RETURNING combined

One thing I really liked is the fact that you can combine those clauses by simply adding RETURNING * at the end of the query. This way any row (or specified columns), either inserted or updated, will be returned.

Real-time app using React, Redux, Tailwind CSS & Firebase - Part 2

Emmanouil Liakos — Sat, 01 May 2021 18:13:06 +0000

1. Setting up Redux
- Why vanilla redux
- Configuring the store
  - Root reducer
  - Application root file
- App component
- Installing Redux devtools
2. Creating FeatureTitle component
- Designing a generic Input component
- Designing FeatureTitle component
- Crafting the state
  - Constants
  - Actions
  - Reducer
3. Adding Firebase persistence
- Connect Firebase with application
- Some tips:
  - Middleware vs Store Enhancers
  - Compose method
  - ApplyMiddleware method
  - Redux Thunk
- Connect Firebase with component
- Debounce function
- Push updates to Firebase
- Receive updates from Firebase

In the previous part we laid out the requirements, planned the architecture and initialized firebase. Now, we are going to setup Redux, connect it to Firebase and create our first component.

Setting up Redux

Why vanilla redux

As stated in the previous part, we are going to use Redux Core and not Redux Toolkit, which includes Redux Core, plus a few other packages and abstractions to make development easier. From the official page:

The Redux Toolkit package is intended to be the standard way to write Redux logic. It was originally created to help address three common concerns about Redux:

"Configuring a Redux store is too complicated"

"I have to add a lot of packages to get Redux to do anything useful"

"Redux requires too much boilerplate code"

The reason we are not going to use Redux Toolkit, or any other similar package is simply because getting to know the intricacies of the tools you use to build important parts of your application - and state management is one of them - is of paramount importance. I'm not talking about learning the internals of webpack here, but knowing how to setup and develop a vanilla Redux project before using various abstractions and templates, IMHO, is a must. Furthermore, you won't be able to understand the core Redux concepts (or Flux architecture, in general) without getting your hands dirty at a "lower level".

Configuring the store

In this series I won't be explaining how Redux works, only providing brief insights and links to any resource I deem useful. If you want to take a deep dive into Redux you will find everything you need in the official page.

Root reducer

The first thing we are going to do is create the root reducer. The root reducer is going to combine all of our reducers inside src/store/reducers. This gives us the ability to namespace our state, by creating different slices of it and separate business logic. As stated in the official FAQ section:

The suggested structure for a Redux store is to split the state object into multiple “slices” or “domains” by key, and provide a separate reducer function to manage each individual data slice. This is similar to how the standard Flux pattern has multiple independent stores, and Redux provides the combineReducers utility function to make this pattern easier.

You can read more about splitting up reducers logic and combineReducers here and here.

Create a file named index.js inside src/store/reducers and type the following code:

import { combineReducers } from "redux";
import feature from "./feature";

export default combineReducers({
    feature
});

Also, create a file named feature.js in the same folder to avoid getting an import error. This is going to be our FeatureTitle component reducer, but just leave it empty for now and ignore the console complaining about not having a valid reducer.

Application root file

The root file of our app, index.js, is going to contain all of the "binding" logic (Provider components) both for Redux and Firebase. It should now look like this:

import React from "react";
import ReactDOM from "react-dom";
import "./index.css";
import App from "./containers/App";

import rootReducer from "./store/reducers/index";
import { createStore } from "redux";
import { Provider } from "react-redux";

const store = createStore(rootReducer);

ReactDOM.render(
    <React.StrictMode>
        <Provider store={store}>
            <App />
        </Provider>
    </React.StrictMode>,
    document.getElementById("root")
);

In the above snippet, we basically pass the root reducer to the createStore method in order to create our store. After that, we pass it as a prop to the Provider component, which is going to wrap the App component and make our React app aware of the store.

App component

Now we should be able to use redux inside our app. Inside src/containers/App.js import some Redux hooks to make sure that everything is running smoothly. It should look like this:

import logo from "../logo.svg";
import "./App.css";

// Import these two hooks from Redux
import { useDispatch, useSelector } from "react-redux";

function App() {

    // Create a dispatcher
    const dispatch = useDispatch();

    return (
        <div className="App">
            <header className="App-header">
                <img src={logo} className="App-logo" alt="logo" />
                <p>
                    Edit <code>src/App.js</code> and save to reload.
                </p>
                <a
                    className="App-link"
                    href="https://reactjs.org"
                    target="_blank"
                    rel="noopener noreferrer"
                >
                    Learn React
                </a>
            </header>
        </div>
    );
}

export default App;

At this point, running npm start to start the development server - if you haven't already -should not produce any error. Next, we are going to install redux-devtools in order to be able to access and debug our state client-side.

Installing Redux devtools

You can basically follow the official instructions, but we'll cover it here, since it's fairly quick. Run:

npm install --save-dev redux-devtools

Then add this argument to the createStore method inside src/index.js:

window.REDUX_DEVTOOLS_EXTENSION && window.REDUX_DEVTOOLS_EXTENSION()

It should now look like this:

const store = createStore(
    rootReducer,
    window.REDUX_DEVTOOLS_EXTENSION && window.REDUX_DEVTOOLS_EXTENSION() // Add this
);

Finally install the chrome extension from the chrome web store. If you are not using chrome or encounter any other issue, please visit the official extension page.

Close and re-open chrome devtools and refresh the page. You should be able to see a tab named Redux. This is where redux devtools live.

NOTE: Later on, we are going to change the way we initialize devtools, because we are going to use store enhancers and middleware.

Creating FeatureTitle component

Now that we've set up Redux we are ready to create our first component! We will begin by designing a generic Input component, then move on to crafting its state and finally add Firebase persistence. By taking a look at our component diagram from the previous part, we can clearly see that FeatureTitle and UserName are simple input components with their functionality doubling as data input and data display. A generic Input component is going to be used to facilitate the creation of FeatureTitle and UserName components.

Designing a generic Input component

Inside src/component create a folder named Input and add a file named index.js. Then paste the following code:

import React from "react";
import PropTypes from "prop-types";

const Input = props => {
    const label = props.label ? (
        <label
            htmlFor={props.name}
            className="block text-sm font-medium text-gray-700"
        >
            {props.label}
        </label>
    ) : null;

    return (
        <React.Fragment>
            {label}
            <input
                type="text"
                name={props.name}
                className={props.className}
                placeholder={props.placeholder}
                onChange={props.handleChange}
                value={props.value}
                disabled={props.disabled}
            />
        </React.Fragment>
    );
};

// Not required, but highly recommended
Input.propTypes = {
    label: PropTypes.string.isRequired,
    name: PropTypes.string.isRequired,
    placeholder: PropTypes.string,
    onChange: PropTypes.func,
    value: PropTypes.string.isRequired,
    disabled: PropTypes.bool.isRequired
};

export default Input;

We created a generic, fairly flexible Input component with dynamic styling, placeholder, etc., to use throughout our app as we see fit.

NOTE: Using propTypes is not necessary, but is highly recommended, especially when not using any other form of type-checking, such as Typescript. Type-checking can help catch bugs, as well as document our code. In this project, we are going to use them, so if you are not going to omit them run npm i prop-types to install the relevant package.

Designing FeatureTitle component

Go ahead and create a folder named FeatureTitlein src/components. Add a file named index.js and paste the component code:

import Input from "../Input";

import { useDispatch, useSelector } from "react-redux";
import setTitle from "../../store/actions/feature/setTitle";

const FeatureTitle = () => {
    const title = useSelector(state => state.feature.title);
    const dispatch = useDispatch();

    const handleTitleChange = event => {
        dispatch(setTitle(event.target.value));
    };

    return (
        <div className="mt-10">
            <Input
                className="items-center px-4 py-2 border border-transparent rounded-md shadow-sm text-sm font-medium focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500"
                handleChange={handleTitleChange}

                // Display loading message while title has a value of null
                value={title === null ? "Loading title..." : title}
                placeholder="Feature title"
                disabled={title === null ? true : false}
                label="Feature Title"
                name="title"
            />
        </div>
    );
};

export default FeatureTitle;

I hope that the code is mostly self-explaining. We basically grab the current title from the central store using useSelector hook (like useState, but for Redux) and assign value and disabled props based on its value. We also create a dispatcher to handle the onChange event, by dispatching the SET_TITLE action along with its payload (the new value).

Crafting the state

Constants

Constants help reduce typos and keep our code more organized. As stated here:

It is often claimed that constants are unnecessary, and for small projects, this might be correct. For larger projects, there are some benefits to defining action types as constants:

It helps keep the naming consistent because all action types are gathered in a single place.

Sometimes you want to see all existing actions before working on a new feature. It may be that the action you need was already added by somebody on the team, but you didn't know.

The list of action types that were added, removed, and changed in a Pull Request helps everyone on the team keep track of scope and implementation of new features.

If you make a typo when importing an action constant, you will get undefined. Redux will immediately throw when dispatching such an action, and you'll find the mistake sooner.

Inside src/store/constants create a file named feature.js and type the following code:

export const SET_TITLE = "SET_TITLE";

Here we are simply exporting a constant named SET_TITLE which is going to be used as an action name to change our component's title.

Actions

Inside src/store/actions create a folder named feature. Any action associated with the FeatureTitle component will be placed in there. Add a file named setTitle.js and paste the following code:

import { SET_TITLE } from "../../constants/feature";

const setTitle = payload => dispatch => {
    dispatch({
        type: SET_TITLE,
        payload
    });
};

export default setTitle;

This action is solely responsible for setting the FeatureTitle value in our Redux store.

Reducer

Inside the feature.js file we created earlier in src/store/reducers, paste the following code:

import * as actionTypes from "../constants/feature";

// The initial state object
const initState = {
    title: null
};

const featureReducer = (state = initState, action) => {
    switch (action.type) {
        case actionTypes.SET_TITLE: {

            // Return new state object
            return {
                title: action.payload
            };
        }

        default:
            return state;
    }
};

export default featureReducer;

As you can see, the reducer is just a function which receives the current state and the action to be performed as arguments and calculates the new state derived from that action.

Adding Firebase persistence

The final step for a working component is adding persistence to our database. To accomplish this, we first need to wrap our app with the Firebase Provider component.

Connect Firebase with application

Head over to src/index.js and add the following imports:

import thunk from "redux-thunk";

// Get internal Firebase instance with methods which are wrapped with action dispatches.
import { getFirebase } from "react-redux-firebase";

// React Context provider for Firebase instance
import { ReactReduxFirebaseProvider } from "react-redux-firebase";

// Firebase configuration
import config from "./config/firebase";

// Firebase SDK library
import firebase from "firebase/app";

Also, modify the redux imports to include applyMiddleware and compose methods:

import { applyMiddleware, createStore, compose } from "redux";

We also need to change the way we initialize devtools:

// Use devtools compose method if defined, else use the imported one from Redux
const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ || compose;

// This will make getFirebase method available to our thunks
const middlewares = [thunk.withExtraArgument(getFirebase)];

and refactor the store to include the new middleware:

const store = createStore(
    rootReducer,
    composeEnhancers(applyMiddleware(...middlewares))
);

Then, wrap the App component with ReactReduxFirebaseProvider like this:

ReactDOM.render(
    <React.StrictMode>
        <Provider store={store}>
            <ReactReduxFirebaseProvider
                firebase={firebase} // Firebase library
                config={config} // react-redux-firebase config
                dispatch={store.dispatch} // Redux's dispatch function
            >
                <App />
            </ReactReduxFirebaseProvider>
        </Provider>
    </React.StrictMode>,
    document.getElementById("root")
);

The end result should be this:

import React from "react";
import ReactDOM from "react-dom";
import "./index.css";
import App from "./containers/App";

// Redux imports
import rootReducer from "./store/reducers/index";
import { applyMiddleware, createStore, compose } from "redux";
import { Provider } from "react-redux";
import thunk from "redux-thunk";

// Firebase imports
import { getFirebase } from "react-redux-firebase";
import { ReactReduxFirebaseProvider } from "react-redux-firebase";
import config from "./config/firebase";
import firebase from "firebase/app";

const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ || compose;
const middlewares = [thunk.withExtraArgument(getFirebase)];

const store = createStore(
    rootReducer,
    composeEnhancers(applyMiddleware(...middlewares))
);

ReactDOM.render(
    <React.StrictMode>
        <Provider store={store}>
            <ReactReduxFirebaseProvider
                firebase={firebase}
                config={config}
                dispatch={store.dispatch}
            >
                <App />
            </ReactReduxFirebaseProvider>
        </Provider>
    </React.StrictMode>,
    document.getElementById("root")
);

In case you face any issues, the official documentation for react-redux-firebase is here.

Some tips:

Middleware vs Store Enhancers

In short:

Middleware adds extra functionality to the Redux dispatch function; enhancers add extra functionality to the Redux store.

You can read more about extending Redux functionality here.

Compose method

The compose method is a utility function often seen in functional programming. As stated here:

You might want to use it to apply several store enhancers in a row.

ApplyMiddleware method

The official description of the applyMiddleware method:

Middleware is the suggested way to extend Redux with custom functionality. Middleware lets you wrap the store's dispatch method for fun and profit. The key feature of middleware is that it is composable. Multiple middleware can be combined together, where each middleware requires no knowledge of what comes before or after it in the chain.

It applies the given middleware and returns a store enhancer.

Redux Thunk

Redux Thunk is a middleware which allows us to create actions that return a function instead of an action object. This function, when called, returns the action object instead which in turn gets passed as an argument to the dispatcher.

Connect Firebase with component

Now that we integrated Firebase with Redux and connected everything to our App component, we can manipulate data saved in Firebase from anywhere, through our Redux store!

Debounce function

First create a file named debounce.js inside src/utils and paste the following code:

export default function debounce(func, wait, immediate) {
    var timeout;
    return function () {
        var context = this,
            args = arguments;
        clearTimeout(timeout);
        timeout = setTimeout(function () {
            timeout = null;
            if (!immediate) func.apply(context, args);
        }, wait);
        if (immediate && !timeout) func.apply(context, args);
    };
}

This is going to be used on inputs and buttons, to prevent aspiring spammers from flooding our database with requests 😏.

Push updates to Firebase

Inside src/firebase create a folder named feature. This folder is going to contain all Feature related firebase functionality/services. Add a file named updateTitle.js and paste the following code:

import debounce from "../../utils/debounce";
import { SET_TITLE } from "../../store/constants/feature";

const updateTitle = ({ ref, payload, oldState, firebase, dispatch }) => {
    firebase
        .ref(ref) // Find reference to update
        .set(payload) // Set new value
        .then(error => {
            // Revert to old state in case of error
            if (error) {
                dispatch({
                    type: SET_TITLE,
                    payload: oldState
                });

                alert("There was an error performing the request.");
            }
        });
};

export default debounce(updateTitle, 500);

This function is going to be used to update the FeatureTitle value in the firebase database. You can check the official Firebase Javascript SDK docs here.

Receive updates from Firebase

Add another action named setupFirebaseListeners.js in src/store/actions/feature and paste the following code:

import { SET_TITLE } from "../../constants/feature";

const setupFeatureListeners = () => (dispatch, getState, getFirebase) => {
    const firebase = getFirebase();

    // Get feature firebase reference
    const featureRef = firebase.database().ref("feature");

    /* Title loading and updates handling */
    featureRef.on("value", snapshot => {
        dispatch({
            type: SET_TITLE,
            payload: snapshot.val().title // New value
        });
    });
};

export default setupFeatureListeners;

This action, once dispatched, will register an event handler for every change in FeatureTitle value update. This event handler will essentially dispatch the SET_TITLE action, in order to update the application state. It will be executed on initial application load, as well as every time the title value changes (by another client, because changes made from us are immediately reflected in the UI for performance reasons, as stated below).

This sums up the two-way binding between our Redux state and Firebase, providing the app with real-time updates.

Head over to src/store/actions/feature/setTitle.js action file and modify it to push updates to Firebase:

import { SET_TITLE } from "../../constants/feature";

// This will handle logic relevant ONLY to firebase update, not Redux state
import firebaseUpdateTitle from "../../../firebase/feature/updateTitle";

const setTitle = payload => (dispatch, getState, getFirebase) => {
    const firebase = getFirebase();
    const state = getState();

    // Getting old title
    const {
        feature: { title: oldState }
    } = state;

    const config = {
        ref: "feature/title", // Path in firebase to update
        payload, // Payload value
        oldState, // Old state object
        firebase, // Firebase instance
        dispatch // Redux dispatch function
    };

    // Update state and firebase independently

    firebaseUpdateTitle(config);

    // Dispatch asynchronously to maintain a responsive UI
    dispatch({
        type: SET_TITLE,
        payload
    });
};

export default setTitle;

NOTE: The key thing to notice here is that we are calling the Firebase middleware function independently of Redux state update (dispatch). This effectively decouples the UI state from the Firebase state. This is important, because if we updated the state after the Firebase promise resolution (either success or failure) then the UI would be unresponsive and laggy. This way, we immediately update the application state, assuming changes were successful and revert to the old one, in case something goes wrong. That's why we pass oldState to firebaseUpdateTitle.

Finally, inside App component import FeatureTitle, initialize main layout and register Feature event handlers. Replace the code inside src/containers/App.js with the following:

import "./App.css";

import FeatureTitle from "../components/FeatureTitle";

import { useDispatch, useSelector } from "react-redux";
import { useEffect } from "react";

import setupFeatureListeners from "../store/actions/feature/setupFirebaseListeners";

function App() {
    const dispatch = useDispatch();

    // Setting up feature listeners
    useEffect(() => {
        dispatch(setupFeatureListeners());
    }, []);

    return (
        <main className="max-w-7xl mx-auto my-5 px-4 sm:px-6 lg:px-8">
            <div className="flex flex-col flex-wrap max-w-3xl mx-auto mt-10">
                <div className="flex justify-center">
                    <FeatureTitle />
                </div>
            </div>
        </main>
    );
}

export default App;

Go to localhost:3000 and you should be able see our component in the center of the page. Open a second tab/browser and try changing the input value. Changes should be synchronized between tabs/windows after the specified debounce timeout (500 ms in this case).

That's it for this part, hope it wasn't tedious. Let me know if you found it interesting.

Any other feedback is also appreciated! Stay tuned for part 3 😎

How to compare accented strings in JS

Emmanouil Liakos — Wed, 28 Apr 2021 16:52:03 +0000

It's a very common scenario when you have to compare strings ignoring their case. The usual approach is to convert both of them to upper or lower case:

const a = 'JavaScript';
const b = 'JAVASCRIPT';

console.log(
  a.toLowerCase() === a.toLowerCase()
); // true

But what about when comparing accented strings (with diacritics) like Café, Jalapeño or résumé ? Here's where the localeCompare method comes in handy. From MDN:

The localeCompare() method returns a number indicating whether a reference string comes before, or after, or is the same as the given string in sort order.

A number 0 means that strings match.

const a = 'Café';
const b = 'cafe';

console.log(
  a.localeCompare(b, 'en', { sensitivity: 'base' })
); // 0 (strings match)

The second argument is the locale and indicates the language, whose formatting conventions should be used. You can omit it by providing a value of undefined.

Real-time app using React, Redux, Tailwind CSS & Firebase - Part 1

Emmanouil Liakos — Sun, 25 Apr 2021 19:24:12 +0000

Hi y' all, this is part 1 of a multi-part series, in which we are going to build a real-time scrum voting app using some of the hottest frontend technologies! 😎

Stack

React & Redux for state management.
Tailwind CSS for quick and effortless styling.
Firebase Realtime Database for storage.

Requirements

The goal is to implement a web application that will be used by a remote scrum team, during their sprint planning session, to privately vote on the complexity score of a single story (task/feature to be implemented).

Full-fledged real-time implementation: All changes will happen in real-time and will be immediately visible to everyone.
Each client gets assigned a default random username when first visiting the app which he can also refresh.
Any participant can edit his/her username, as well as the feature-to-be-implemented title.
Any participant can vote and reveal all votes, effectively ending the session.
While votes are hidden, any participant that has voted gets a "Voted!" message next to his/her username.
When votes are revealed, users get reordered based on their votes. After that, anyone is able to reset the session, clearing all votes and resetting the feature title.

End result

You can check it live here.

The code is also here.

Phew, that seemed quite overwhelming 🤯. This project was part of a code challenge, so don't put the blame on me 😂 Anyway, let's get down to it.

Planning the application

One of the first things that I do when I start working on a front-end application is meticulously plan its architecture.

I visually divide the app into logical, self-isolated components with discrete functionality.

Then I search for reusable components which will either be placed in a commonmodule folder (in bigger projects) or will just be created with reusability in mind (dynamic, prop-based styling, etc.).

Wrappers are also reusable components which wrap other (child) components to provide them with extra functionality (visual or logical). They are officially called HOCs or Higher Order Components. I search for those kind of components, too. Imagine a Layout component which wraps our pages and provides them with static elements like Header, Footer, Menu, etc. or a Card component which wraps its children in a card-like element.

Next, I try to delegate possible state to each one of them (identifying stateful and stateless components), in case we are not using a centralized store for state management. In this case we will be using Redux, so only purely local state will be in-component.

Finally, I plan the app's folder structure as well as possible. Should the need to make changes down the road arise, especially if the app grows, a solid foundation is going to make for a resilient app.

Components

By taking a look at the image above, one could easily distinguish between the following components:

Wrappers (HOCs)

Card (Used to wrap VotingArea & Users/Participants components)

Common/reusable

Button
Input

Normal

FeatureTitle (Based on Input component)
Heading
- Username (Based on Input component)
Users
- User
VotingArea

Stateful

All of our state is going to live in the Redux store, so no planning is going to take place in here 😊

Folder structure

Our app's code will live in src folder and is going to have the following structure:

├──src
   ├──__tests__
       ...test files...
   ├──common
      ...common functions used by many components...
   ├──components
      ...all of our components...
   ├──config
      ...configuration files...
   ├──containers
     ...I just left the App here as a container 😅...
   ├──firebase
     ...firebase service...
   ├──store
      ...our redux store...
      ├──actions
      ├──constants
      ├──reducers
   ├──utils
      ...helper functions...

I hope it's mostly self-explaining. We are going to add some more folders in a later part, but for now, a bird's-eye view should do it.

Initialize application

To initialize our app, run:

npx create-react-app scrum-voting-app

Install dependencies

Tailwind CSS

You can pretty much follow the official instructions here, there's no point in repeating them in this post.

Redux

We're going to use plain redux without any helpers (i.e. redux-toolkit). We are also going to use redux-thunk middleware to handle our async actions.

Run:

npm i redux react-redux redux-thunk

Firebase

Here we need two libraries, firebase and react-redux-firebase. The first one is the Firebase SDK needed to connect to our database instance. The second one provides us with Redux bindings for Firebase in order to make our lives easier.

Run:

npm i firebase react-redux-firebase

Modify files and structure

Create a folder called containers and move App.js and App.css in there and change the relative import in index.js accordingly:

import App from "./containers/App";

Also change the logo import in App.js to avoid any errors:

import logo from "../logo.svg";

Create the rest of the folders inside src, as seen in the Folder Structure section above. You can also delete App.test.js file or move it inside __tests__ folder.

Setting up Firebase

The next step, after we've finished drafting our application's blueprint, is to set up Firebase.

Firebase is a cloud JSON database which lets us store data in key-value pairs. Its Realtime Database flavor gives us the ability to synchronize every client using emitted events. All we have to do is utilize the API and create our handlers. Pretty cool, right? 🥳

Create an account

Go to https://console.firebase.google.com/ and login with your google account. Create a new project by clicking on "Add project". Type a name and optionally enable Analytics.

Create a database

Click on "Realtime Database" in the menu bar and then "Create Database". Choose a location and then "Start in test mode" to have our app publicly accessible to everyone. You can change this later if you want to add authentication and whatnot. Boom, you're up and running!

Adding a configuration file

Go to your project settings in Firebase console (Project Overview > Project Settings) and scroll down to "Your apps" section. Select our app and under "Firebase SDK snippet" choose "Config". This is our config object, copy it.

Create a file called firebase.js inside config folder and paste the config object and some additional code, likewise:

import firebase from "firebase/app";
import "firebase/database";
import "firebase/analytics";

// Configuration object copied from firebase console
const firebaseConfig = {
    apiKey,
    authDomain,
    databaseURL,
    projectId,
    storageBucket,
    messagingSenderId,
    appId,
    measurementId
};

// Initialize Firebase
firebase.initializeApp(firebaseConfig);
firebase.analytics();

export default firebase.database();

Now we're ready to use our database.

That's it for this part, I hope you found it interesting.

Let me know if you catch any errors and stay tuned for part 2!

Quick tips on writing better React code

Emmanouil Liakos — Sun, 28 Feb 2021 11:40:54 +0000

In this short post I am sharing some best practices that I've learned, during my journey writing React applications.

Common module

Buttons, inputs, cards are some examples of components that are used all over our application. Unless we want everyone to create his own Button, we should create a common module to accommodate those components. This way we abide to the DRY principle, as well as ensure consistency across our application.

Abstract functionality

We should keep our components clean and succinct, by extracting complex functionality into new functions. For example, if we are fetching data from a Firebase instance, we should create a separate firebase folder and put all of our logic in there, instead of polluting our components with fetching hooks and whatnot. Also, whenever we find ourselves using a certain method more than 2-3 times, we should probably outsource it in a function itself. I usually like to create a helper or utilities folder for this kind of thing.

Folders for components

When multiple files are associated with our components, we should probably group them in folders for better project navigation. Also, in order to avoid having repetitive import statements, we could use an index.js file to export our component. This way, we can ommit the filename, assuming webpack is configured to import from index.js by default.

For example, if we choose to use CSS modules for component styling and maybe like to have our tests close to the tested component, we should structure our components like this:

├──Dashboard
   ├──TopMenu
      ├──index.js
      ├──TopMenu.module.css
      ├──TopMenu.jsx
      ├──TopMenu.test.js
   ├──Viewport
      ├──index.js
      ├── Viewport.jsx
      ├──Viewport.module.css
      ├── Viewport.test.js
   ├──BottomMenu
      ├──index.js
      ├──BottomMenu.jsx
      ├──BottomMenu.module.css
      ├──BottomMenu.test.js

Solid project structure

I like to think of my project structure in terms of business logic/functionality, not technical details. Each part of our application should reflect its "business responsibilities". A module-based approach is a resilient architecture that's going to allow us to confidently add functionality as our application grows.

├──modules
   ├──Dashboard
      ...
   ├──Users
      ...
   ├──Analytics
      ...
   ├──Inventory
      ...

Props destructuring

There is no need to constantly refer to props inside our functional components. We can use ES6 destructuring feature to avoid this, as follows:

const User = ({ name, lastname }) => {
  return (
    <div>
      <p>Name: {name}</p>
      <p>Lastname: {lastname}</p>
    </div>
  );
};

export default User;

Named components

Naming our components is something that's going to be helpful when debugging using the error stack trace. It's the same as with anonymous arrow functions: While they are great for readability, they appear less helpful when debugging.

That's it, I hope you found it useful!

DEV Community: Emmanouil Liakos

Jest with TypeScript and aliased imports (custom paths)

Install Jest

Add TS support

Add path support

Cleaner imports with aliases in react and typescript ✨✨

The problem with relative imports

Configuring aliased imports

TypeScript configuration

Webpack configuration

How to handle boolean values in SQLite using JavaScript Proxies

The problem with Booleans in SQLite

2.1. Boolean Datatype

Welcome ES6 Proxies 👋

Writing the helper function

Using proxies to intercept query calls

Conditional GitHub action based on commit message

Real-time app using React, Redux, Tailwind CSS & Firebase - Part 3

Table of contents

Setting up

Creating Heading component

Creating UserName component

Crafting the state

Constants

Actions

Reducers

Adding Firebase persistence

Push updates to Firebase

Receive updates from Firebase

Debug Electron production binaries on Windows, Mac & Linux

Windows

Mac

Unsigned binary

Signed binary

Linux

CRLF: Mind the line

Introduction

LF: Line feed

CR: Carriage Return

CRLF: Carriage Return - Line Feed

The bug

The fix

Some quick history

References

Quick post about the SQLite UPSERT and the new RETURNING clause.

The RETURNING clause

The UPSERT clause

UPSERT & RETURNING combined

Real-time app using React, Redux, Tailwind CSS & Firebase - Part 2

Table of contents

1. Setting up Redux

2. Creating FeatureTitle component

3. Adding Firebase persistence

Setting up Redux

Why vanilla redux

Configuring the store

Root reducer

Application root file

App component

Installing Redux devtools

Creating FeatureTitle component

Designing a generic Input component

Designing FeatureTitle component

Crafting the state

Constants

Actions

Reducer

Adding Firebase persistence

Connect Firebase with application

Some tips:

Middleware vs Store Enhancers

Compose method

ApplyMiddleware method

Redux Thunk

Connect Firebase with component

Debounce function

Push updates to Firebase

Receive updates from Firebase

How to compare accented strings in JS

Real-time app using React, Redux, Tailwind CSS & Firebase - Part 1

`LF`: Line feed

`CR`: Carriage Return

`CRLF`: Carriage Return - Line Feed