Learning Outcomes - 20th April

The past week, I’ve learnt a few things, some of which include:

Using propTypes in react to provide validations.
I used methods like:
- propTypes to specify the type of the expected props.
- isRequired to ensure that some components always need certain props to be rendered.
- defaultProps to have a default value in case no value is passed for a certain prop.

Using propTypes has made my code cleaner.
Before: I had to first check that the required prop has been provided before I can use it.
After: no need to check that the required prop exists.

// Before
function Board(props){
    props.board && display(props.board)
}

// After
function Board(props) { display(board) }

Board.defaultProps = { board: []; };

Fragments in React
Because react requires you to have one parent wrapper for each component, you sometimes find yourself creating a div that has no unique properties other than just satisfying this rule.
React Fragments can be used instead since they add no extra node to the application and can still wrap the elements as a single wrapper.

// Before
function App(){
  return ({
    <div>
        <Rules />
        <Board />
    </div>
  });
}

// After
function App(){
  return ({
    <React.Fragment>
        <Rules />
        <Board />
    </React.Fragment>
  });
}

Shared example in Ruby
As I was trying to figure out a way of having an interface in ruby that could be implemented, I found out that are 2 common ways this is done.
1. having a module that declares the methods and their bodies raising not implemented.
2. using shared examples in tests to enforce the behaviour of an interface
I picked interest in the latter example mainly because the first one can only be caught at runtime in case a class hasn’t implemented a method, whereas shared examples are caught while running the tests.

usage:
shared_example are declared to describe the shared behaviour between 2 classes. A spec file is created to describe the behaviour and all the classes with the same behaviour simply include this support spec in order to enforce the behaviour.

# shared example
shared_examples "datastore interface" do
  it { is_expected.to respond_to(:store) }
  it { is_expected.to respond_to(:load) }
end

# imlplements sahred example
describe PostgresDatabase do
    include_examples 'datastore interface'
 end

Dynamic Dispatch
Dynamic dispatch is calling a method at runtime. This method can change based on the code. In ruby using the keyword public_send on an instance of a class can call the class methods.

def load(id, key)
    @data.find(id).public_send(key)
end

The danger with this is that it let’s the user specify the key which can lead to undefined methods called or restricted methods calls.

References

https://reactjs.org/docs/typechecking-withproptypes.html
https://reactjs.org/docs/fragments.html
http://morningcoffee.io/interfaces-in-ruby.html