DEV Community: Michael Kochell

How to avoid pushing to branches that are not protected (that should be)

Michael Kochell — Tue, 01 Oct 2019 23:34:34 +0000

Git hooks are used to run some arbitrary code before and after different git operations. The ones that begin with pre- are used before the operation, and can be used to bail out of the operation. post- hooks are run after an operation, but do not have built-in functionality revert the operation itself.

We're going to use pre-commit and pre-push hooks to make sure we never accidentally commit/push to an un-protected master branch. It is only going to affect our own local copies of the repositories. You will need git 2.9+ (June 2016). The script we will create will ask you if you want to commit/push to master, so you will still be able to if that's your intention.

Make a place to house your global hooks.

mkdir ~/.githooks

Create a file called pre-commit in this directory.

#!/bin/bash

protected_branch='master'
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')

if [ $protected_branch = $current_branch ]
then
    read -p "You're about to commit to $protected_branch, is this what you intended? [y|n] " -n 1 -r < /dev/tty
    echo
    if echo $REPLY | grep -E '^[Yy]$' > /dev/null
    then
        exit 0 # push will execute
    fi
    exit 1 # push will not execute
else
    exit 0 # push will execute
fi

We should also make a pre-push hook. To do this, copy the pre-commit file to a new file pre-push, and change to the prompt to say "push" instead of "commit". pre-commit is arguably more important and sort of renders pre-push useless. You can never be too careful though.

Set the files to be executable:

chmod a+x ~/.githooks/pre-commit
chmod a+x ~/.githooks/pre-push

Set your global hooks folder to be recognized by git:

git config --global core.hooksPath ~/.githooks

Now if you try to commit or push to master on any repo on your machine, the hook will ask you to make sure you want to do that.

If you want to apply this on a per project basis, then you will need to add the pre-push and pre-commit files to the project's .git/hooks folder instead of a global hooks folder.

Sharing Context with React Portals

Michael Kochell — Wed, 24 Oct 2018 07:09:49 +0000

State management in React is a widely discussed topic on the internet. While the most common approach for large applications seems to be Redux, there has been a lot of attention on the improvements of the React Context API. Using render props, we can now access state being held far up the tree with ease. For a single page application, this is ideal because the whole application is one tree.

However, if you are mounting several trees of components throughout the page (in my case I'm using Ruby on Rails and Webpacker React to render the components), the different trees cannot use the same provider as a common ancestor. Hence, they cannot share the same state. So how do we get the different trees to play nicely together?

React Context + React Portals

Using a syntax very similar to:

ReactDOM.render(<MyComponent />, domElement);

We can use

const PortalComponent = React.createPortal(<MyComponent />, domElement);

to render multiple components in the same React tree, among different isolated parts of the DOM. Using React.createPortal() we can create a new React component to be rendered at the specified DOM node.

What's different about createPortal() when compared to ReactDOM.render(), is that the component is not rendered at the point of calling createPortal(). We use the return value of React.createPortal() (a new React component), and render it in our tree. Here's an example where we are rendering components with different entry points throughout the page:

/* first let's define a context to share */
/* important_value_context.jsx */

import React from 'react'

const Context = React.createContext({})

export class ImportantValueProvider extends React.PureComponent {

  state = {
    importantValue: 'Cake is good',
    updateImportantValue: this.updateImportantValue,
  }

  updateImportantValue = importantValue => this.setState({importantValue})

  render() {
    return (
      <Context.Provider value={this.state}>
        {this.props.children}
      </Context.Provider>
    )
  }
}

export default Context


/* main.jsx */

import React from 'react'
import ReactDOM from 'react-dom'

import {ImportantValueProvider} from 'path/to/important_value_context'
import CoolComponent from 'path/to/cool_component'
import SuperCoolComponent from 'path/to/super_cool_component'

const Main = () => {

  const ComponentA = () => ReactDOM.createPortal(
    <CoolComponent />,
    document.getElementById('banner'),
  )

  const ComponentB = () => ReactDOM.createPortal(
    <SuperCoolComponent />,
    document.getElementById('footer'),
  )

  return (
    <ImportantValueProvider>
      <ComponentA />
      <ComponentB />
    </ImportantValueProvider>
  )
}

ReactDOM.render(
  <Main />,
  document.getElementById('main'),
)

Instead of making two calls to ReactDOM.render(), we create two portals and render both under our top-level Provider. ComponentA and ComponentB will be rendered in two different points in the DOM, but they share the same React tree, thanks to portals. They can both import ImportantValueContext and reference its consumer to communicate with the same instance of ImportantValueContext.

/* cool_component.jsx */

import React from 'react'

import ImportantValueContext from 'path/to/important_value_context'

class CoolComponent extends React.PureComponent {
  render() {
    return (
      <ImportantValueContext.Consumer>
        {sharedState => (
          <div>
            <input
              value={sharedState.importantValue}
              onChange={e => sharedState.updateImportantValue(e.target.value)}
            />
          </div>
        )}
      </ImportantValueContext.Consumer>
    )
  }
}

export default CoolComponent


/* super_cool_component.jsx */

import React from 'react'

import ImportantValueContext from 'path/to/important_value_context'

class SuperCoolComponent extends React.PureComponent {
  render() {
    return (
      <ImportantValueContext.Consumer>
        {sharedState => (
          <h1>{sharedState.importantValue}</h1>
        )}
      </ImportantValueContext.Consumer>
    )
  }
}

export default SuperCoolComponent

Now CoolComponent and SuperCoolComponent can share state with the same ImportantValueProvider. That's fantastic news if you plan on sprinkling components into an existing webpage... if you're into that sort of thing.

NOTE: This applies to working with Redux providers as well, though using context was my use case so I put emphasis on that instead.

Quick Google search from terminal

Michael Kochell — Wed, 24 Oct 2018 05:38:44 +0000

Note: this only applies to MacOS

Often times while I'm working on a project, I'll need to search for something on the internet to solve a problem. I usually use the search engine created by Google, called Google. When I need to search for something, I always have to stop what I'm doing, and switch over to a browser to type in my search. This may not seem like a big deal because it doesn't take that much time, but in reality this is a context switch. There is a momentary discontinuity in the intentions of your search.

I'd like to remove this obstacle and be able to search without leaving my development environment. This can be accomplished by using the open command on MacOS, and the chromium-browser command on Linux.

Place this script in your PATH with the name "gsearch":

~/scripts/gsearch


#!/bin/sh

# If using mac
open "https://google.com/search?q=$*"

# If using linux and chromium
chromium-browser "https://google.com/search?q=$*"


# Now you can enter a search query like this:
gsearch please help google

A browser tab will then come into focus, showing the results for a Google search of "please help google". Now that's good DX.