Forem: Sadick

The Only Way to Achieve Continuous Integration.

Sadick — Thu, 12 Oct 2023 07:31:00 +0000

Single Branch.

The only way to achieve continous integration is through Trunk-Based Development. Trunk-based development is based on the idea that there is a single branch i.e main|master|dev|trunk in which all the developers on your team commit to frequently (at least once everyday).

The confusion around continous integration.

I have heard countless times people describe continous integration in terms of tools. They think continous integration is the process of passing code changes through a tool which produces results ✅ at the end of the process. That thinking is even made worse with how some tools name themselves. i.e CircleCI, Gitlab CI e.t.c.

Continous integration is the act of developers merging their code changes together frequently.

The issue with branching.

Most if not all of us are used to branching. Whenever there is a new feature we want to develop, we create a branch for it. If there is a bug, we create a branch to fix the bug. Branching has become part and parcel of our everyday work. We create branches to isolate our changes. But is creating branches the best way to work with your team?

Below are some of the issues I see with branching.

Isolated development.

When developers work on different branches they may not always be aware of what the other developers are doing. It is possible that the developers might be changing the same piece of code without them knowing. Distance is created because every developer will only be concerned with the changes they want to bring in therefore forming silos.

Working in this way means developers hide changes from each other untill they are ready to show them. As developers we should be embracing change not hiding it.

Complexity of conflicts.

As the number of branches and the complexity of the codebase increase, so does the likelihood of conflicts. Complex conflicts can be challenging to resolve because they may involve changes in multiple files or dependencies. I know you have experienced this at least a couple times and its not fun to deal with. I have never met a developer who likes to resolve conflicts.

Developers working in isolation on their branches may miss opportunities for collaboration and sharing of ideas, leading to missed improvements and innovation. The lack of collaboration inhibits collective ownership of the code. No developer feels its their responsibilty to make sure the code is stable and easy to work with.

Implementing Trunk-Based Development.

Have single branch, where your teams commit to thats it. But this creates other issues like,

How handle code reviews.
What about big features?

Blindly implementing single branch for all your teams' work leads to alot of chaos. For trunk-based development to be successfull there are a couple of guidelines that you can follow.

Small changes.

Every commit should be small, buildable and testable. The smaller the change between two working states the easier it is to find and fix any issue introduced by that change.
How small is small? A small commit is a commit that addresses a single task or issue and makes a meaningful change to the codebase.

Frequent commits.

You and your team need to commit frequently and push the commits. This ensures faster integration with everyone elses code. Frequent commits also reduces the likelyhood of hard to resolve merge conflicts. When you and your team are pushing regularly, it gives your team a change to see each others work, which encourages collaboration.

Keep the pipeline green.

If for some reason the build is broken, then your team should drop everything they are doing to fix the build. This will ensure no problematic change makes it to production. Also your team should make it a habit to test and build on their own machines before pushing it to the build pipeline. 😉

Keep your builds fast ⚡

When you are making small commits, you wouldn't want to be slowed by the build speed. You should strive to bring your build speed down to seconds. You could use strategies like cached builds or incremental builds to improve the speed of your builds.

All the above guidelines are good, but still doesn't answer the questions like, code reviews and big features.

How handle code reviews.

You could review code after the integration after a section of code has received significant changes.
You could introduce pair programming, were two people would work on a feature together. Since their is an extra eye on your work most issues will be caught by your programming pair. You could consider the commit you made reviewed when working with another person on a problem.
If you are adventurous you could even try Mob programming. That is where you have more than 2 people working on a task. Mob programming is very effective when it comes to knowledge sharing.

Handling big features.

Since you will be doing small, single focused commits frequently, there is no way you will fit a big feature into a single commit. You will likely make more commits before a feature is considered done.

One way to handle this is through feature flags.

You would start by creating a feature flag for the feature you are working on and keeping it turned off. Once you complete all the work neccessary for the feature you would turn the feature on. After some monitoring, if you are convinced that the feature is working as intented in production, you will need to delete the feature flags from your code and the platform you use to manage the feature flags.

Even if you are not ready to adopt trunk-based development, at least keep your commits small and focused on a single well defined task.✌️

Being a good programmer is 3% talent and 97% not being distracted by the internet.

Sadick — Wed, 12 Aug 2020 04:25:08 +0000

Mental Models: Array Indexing

Sadick — Thu, 07 May 2020 05:00:08 +0000

Having arrays start at index zero is somewhat confusing at first. Naturally we start counting things from one. We see zero as representing nothing.

The confusion comes from thinking of the index as an ordinal number. An ordinal number defines the position of something in a series i.e. first, second, third e.t.c. This logically means we can't have an item occupying position zero in a series. If we think of the index as an ordinal number, the first element would be at e[1].

Your thinking should shift from thinking of index as an ordinal number. You should be thinking of the index as an offset from a starting point. From this thinking the first element would be a distance of zero from the beginning, hence e[0].

Universal next gen css-in-js library in under 1kb

Sadick — Tue, 18 Sep 2018 11:46:38 +0000

Introducing `scoped-style`

Scoped style aims to be a universal library that you can use to style your components while still maintaining a small footprint.

It has currently been tested with react, preact and hyperapp. You can use the full power of css just as you are used to.

yarn add scoped-style

Examples

import scoped from "scoped-style"

// for react
import React from "react"
const styled = scoped(React.createElement)
//

// for Preact
import { h } from "preact"
const styled = scoped(h)
//

// for Hyperapp
import { h } from "hyperapp"
const styled = scoped(h)
//

const Button = styled("button")`
  background: ${props => props.primary ? "orange": "gray"};
  border: none;
  border-radius: 2px;
  :hover {
    padding: 10px;
  }
`

const App = () => (
  <div>
    <Button primary>Login</Button>
  </div>
)

// Your rendering code

The project is on github. Contributions are highly welcomed.

Hot reloading preact with parcel, the missing doc

Sadick — Tue, 11 Sep 2018 14:10:27 +0000

Today I was setting up a preact app with parcel as the bundler. Before I could even start building the app, I suddenly hit a snag. Whenever I made a change to my components, my changes were being appended to the html doc instead of being replaced.

It turns out parcel is not the issue, preact is. I went to their docs as any developer would. I found out their their render by default appends to the node specified. The preact render function accepts a third argument which is supposed to be the node to be replaced.

So to fix the appending problem, I needed to provide the third agrument.

import { h, render } from "preact";

const Happy = () => <div>Happy</div>;
const App = () => (
  <div>
    <Happy />
  </div>
);
const node = document.getElementById("root");

render(<App />, node, node.lastChild);

Now it behaves as expected. Maybe parcel should update their docs to include this. I wanted to make a pull request but their docs are not on github.

You don't need express to get started with socket.io

Sadick — Wed, 08 Aug 2018 06:55:10 +0000

The best place to get started with socket.io is their website. But once you access it you are given this example app demonstrating how to use socket.io.

var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);

app.get('/', function(req, res){
  res.sendFile(__dirname + '/index.html');
});

io.on('connection', function(socket){
  console.log('a user connected');
});

http.listen(3000, function(){
  console.log('listening on *:3000');
});

If you are fairly new to node, this makes you think that express is needed in order to use socket.io. In the above example they include express to serve the index file which will be client app for your socket server. There is nothing wrong with the above approach but if lets say you don't know express, now you have one more thing to learn before using socket.io.

It would be better if they didn't introduce an additional library in their example. Socket.io has another example using the node http server

var app = require('http').createServer(handler)
var io = require('socket.io')(app);
var fs = require('fs');

app.listen(80);

function handler (req, res) {
  fs.readFile(__dirname + '/index.html',
  function (err, data) {
    if (err) {
      res.writeHead(500);
      return res.end('Error loading index.html');
    }

    res.writeHead(200);
    res.end(data);
  });
}

io.on('connection', function (socket) {
  socket.emit('news', { hello: 'world' });
  socket.on('my other event', function (data) {
    console.log(data);
  });
});

But even this is a little bit too much. I prefer having the server and the client seperate. Therefore this would be my server.

const io = require("socket.io");
const server = io.listen(3000);

server.on("connection", function(socket) {
  console.log("user connected");
  socket.emit("welcome", "welcome man");
});

And the client would include the socket.io client library and just plain html.

<html>
    <head>
        <title>Socket io client</title>
        <script src="http://localhost:3000/socket.io/socket.io.js"></script>
        <script>
            var socket = io("http://localhost:3000");
            // use your socket
            socket.on("welcome", (message) => {
                // do something with the message.
            })
        </script>
    </head>
    <body>
    </body>
</html>

How do you measure developer productivity in your team?

Sadick — Tue, 24 Jul 2018 16:11:48 +0000

139 Traits That Make A Better Programmer

Sadick — Mon, 23 Jul 2018 14:16:01 +0000

Lets face it, every developer wants to improve and become better. The big question that most developers ask is how will I do it. Here are a list of things you should keep in mind while programming.

Code Presentation

As any discussion about code layout grows, the probability of it descending into a fruitless argument approaches one. You know the tabs vs spaces, bracket placement weather on new line or the same line.
A good code format is not the one you think looks prettiest. A good format is the one that makes it easier to scan and read the code.
Good code presentation reveals your code’s intent. It is not an artistic endeavor.
We need good presentation to avoid making code errors. Not so we can create pretty ASCII art.
We write code to be executed by a computer, but to be read by humans.
If any man wishes to write a clear style, let him first be clear in his thoughts.
Pick one layout style and use it consistently or adopt coding standard or style guide.
If you’re working in a file that doesn’t follow the layout conventions of the rest of your project, follow the layout conventions in that file.

Naming

A good name is descriptive, correct, and idiomatic.
You can only name something well if you know exactly what it is. Make sure you know what it is before giving cryptic names to variables.
Avoid redundancy. It shows you didn’t think through the naming of what you are building. Be it a class or function or variables

class ItemList {

public int numberOfItems () {…}

}
// numberOfItems is unnecessarily long, repeating the word Item
// it could be renamed to size or even length

Employ the capitalization conventions most often used in your language. Like in C# methods are capitalized Console.WriteLine("Hello World")
Ensure that your names are accurate and avoid spelling mistakes.
Never alter presentation and behavior at the same time. Make them separate version-controlled changes.
Adapt your presentation style as you gain experience. As a beginner you don’t always start out with good code presentation, your are more concerned about whether the program works or not.

Write Less Code

Writing lots of code does not mean that you’ve written lots of software. It may just mean you are written lots of bugs.
More code means there is more to read and more to understand — it makes our programs harder to comprehend.
The more code you have, the more places there are for bugs to hide and tracking them down may not be that easy.

Avoid Unnecessary Code

Common class of pointless code is the unnecessary use of conditional statements and tautological logic constructs. Flappy logic is the sign of a flappy mind.

// example
if (expresion) {
  return true;
} else {
  return false;
}
// which can be refactored to
return expresion;

Express code clearly and succinctly. Avoid unnecessarily long winded statements. They don’t add any value to your code.

Duplication

Do not copy code sections. Factor them into a common function. Use parameters to express any differences.
If you spot duplication, remove it.

Dead Code

Dead code is code that is never run, that can never be reached.
Tell your code to get a life, or get lost.

Other manifestations of dead code include:

Functions that are never called
Variables that are written but never read
Parameters passed to an internal method that are never used
Enums, structs, classes, or interfaces that are never used

Comments

Good code does not need reams of comments to prop it up, or to explain how it works.
Make sure that every comment adds value to the code. The code itself says what and how. A comment should explain why — but only if it’s not already clear.
Do not remove code by commenting it out. It confuses the reader and gets in the way.
Every day, leave your code a little better than it was. Remove redundancy and duplication as you find it.

Improve Code by Removing It

You can improve a system by adding new code. You can also improve a system by removing code.

How dead code spring up during development

Features are removed from an application’s user interface, but the backend support code is left in.
Wizard-generated UI code inserts hooks that are frequently never used.
Remove dead code wherever possible. It gets in the way and slows you down.
It is safe to remove code that you might need in the future. You can always get it back from version control.
Code cleanup should always be made in separate commits to functional changes.
Dead code happens in even the best codebases.

Be wary of the Past

You thought it was perfect when you wrote it, but cast a critical eye over your old code and you’ll inevitably bring to light all manner of code gotchas.

Looking back at your older code will inform you about the improvement (or otherwise) in your coding skills.

How to go about an existing codebase

Coming into any large existing codebase is hard. You have to rapidly:

Discover where to start looking at the code
Work out what each section of the code does, and how it achieves it
Gauge the quality of the code
Work out how to navigate around the system
Understand the coding idioms, so your changes will fit in sympathetically
Find the likely location of any functionality (and the consequent bugs caused by it)
Your best route into code is to be led by someone who already knows the terrain. Don’t be afraid to ask for help!
The best way to learn code is to modify it. Then learn from your mistakes.
Many programmers, rather than putting in the effort to read and understand existing code, prefer to say “it’s ugly” and rewrite it.
Be prepared to encounter bad code. Fill your toolbox with sharp tools to deal with it.
Some filthy code was simply written by a less capable programmer. Or by a capable programmer on a bad day.
Silence the feeling of revulsion when you encounter “bad” code. Instead, look for ways to practically improve it.
You can’t expect any code, even your own, to be perfect.
Follow the Boy Scout Rule. Whenever you touch some code leave it better than you found it.
Make code changes slowly, and carefully. Make one change at a time.

Dealing with Errors

Do not ignore possible errors in your code. Don’t put off handling errors until “later” (you won’t get around to it).
Use exceptions well, with discipline. Understand your language’s idioms and requirements for effective exception use.
Programmers must be made aware of programmatic errors. Users must be made aware of usage errors.
It’s not good enough to log the error (somewhere), and hope that a diligent operator will notice an error and do something about it one day.

Be prepared for the Unexpected

At every step, consider all of the unusual things that might occur, no matter how unlikely you think they’ll be.
Always consider errors that you can recover from, and write appropriate recovery code.
Ensure that your error handling is idiomatic, and uses the appropriate language mechanisms.
Consider all potential code paths as you write your code. Do not plan to handle “unusual” cases later: you’ll forget and your code will be buggy.

Bug Hunting

Programmers write code. Programmers aren’t perfect. The programmer’s code isn’t perfect. It therefore doesn’t work perfectly the first time. So we have bugs.
We should always employ sound engineering techniques that minimize the likelihood of unpleasant surprises.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Reduce bugs to the simplest set of reproduction steps possible.
Ensure that you are focusing on a single problem.
Assertions and logging (even the humble console.log and nodejs assert) are potent debugging tools. Use them often.
Binary chop problem spaces to get results faster.
As you develop your software, invest time to write a suite of unit tests.
Untested code is a breeding ground for bugs. Tests are your bleach.
Learn how to use your debugger well. Then use it at the right times.
Fix bugs as soon as you can. Don’t let them pile up until you’re stuck in a code cesspit.
Debugging isn’t easy. But it’s our own fault. We wrote the bugs.

Always test your code

Unit tests specifically exercise the smallest “units” of functionality in isolation, to ensure that they each function correctly. This isolation specifically means that a unit test will not involve any external access: no database, network, or file system operations will be run.

Quality is free, but only to those who are willing to pay heavily for it.
To improve our software development we need rapid feedback, to learn of problems as soon as they appear. Good testing strategies provide short feedback loops.
Write tests as you write the code under test. Do not postpone test writing, or your tests will not be as effective.
All tests should run on your build server as part of a continuous integration tool chain.
Test whatever is important in your application.
Global variables and singleton objects are anathema to reliable testing. You can’t easily test a unit with hidden dependencies.
Factoring your code to make it “testable” leads to better code design.
Program testing can be used to show the presence of bugs, but never to show their absence.

How to deal with complexity

Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.
Complexity is generally accidental, rarely something someone adds willfully.
Defer design decisions until you have to take them. Don’t make architectural decisions when you don’t know the requirements yet. Don’t guess.

Practice Makes Perfect

A programmer needs good taste and a sense of aesthetics to write exceptional code.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.
Good software development is not cowboy coding, throwing down the first code you can think of. It is a deliberate, considered, accurate endeavor.
Good programmers work with humility. They admit that they don’t know it all.
Good code and good coders are born from a desire to write the right thing in the right way.

Be a team player

Programming teams have a set of rules. These rules define what we do and how we do it. But they also describe a coding culture.
Don’t rely on vague unwritten team “rules.” Make the implicit rules explicit, and take control of your coding culture.
Apply bug fixes to the root cause, not where symptoms manifest. Sticking plaster symptom-fixes do not lead to simple code.
Avoid implicit assumptions in your code.
Only write as much code as is needed. Anything extra is complexity that will become a burden.
Stop and think. Don’t write stupid code.
Admit to your mistakes and bad coding decisions. Learn from them.
Have the courage to use your brain. Feel empowered to critique code and make decisions about how to improve it.
Learn what makes software easy to change, and strive to craft software with these attributes.
To modify code you need courage and skill. Not recklessness.
Often it is best to make a series of frequent, small, verifiable adjustments, rather than one large sweeping code change.
Avoid copy-and-paste coding. Factor your logic into shared functions and common libraries, rather than suffer duplicated code (and duplicated bugs).
Write small, modular sections of code. Keep it clean and neat.
Code should be “shared” because it is useful to multiple clients, not because the developers want to create a nifty shared library.
Don’t dismiss other people’s code. It may be better to use existing libraries rather than write your own version.
Creating software releases requires discipline and planning. It is more than hitting “build” in a developer’s IDE.
Always build your software in a fresh checkout, from scratch. Never reuse old parts of a software build.
Make your build as simple as a single step that automates all parts of the process. Use a scripting language to do this.
Deploy your builds on a CI server to ensure their health. Make formal releases from the same system.
Be in a state of continual learning. Always look to learn something new.
Our learning is often too narrowly focused. Consider a wider sphere of reference. Draw inspiration from many fields.
Takes notes as you learn. Even if you throw them away.
If you can’t explain it simply, you don’t understand it well enough.
Teach a topic to learn that topic well.
I hear and I forget. I see and I remember. I do and I understand.
Using what you just learned cements it in your memory. Try examples, answer questions, create pet projects.
Be wary of stagnation. Seeking to become a better programmer, by definition, is not the most comfortable lifestyle.
Expect to invest time and effort to grow your skill set. This is a worthwhile investment; it will repay itself.
Do not make yourself “indispensable” by writing unreadable or unnecessary “clever” code.
Honour software licenses.
Don’t become a one-trick pony. Position yourself to face new challenges, learn, and grow as a developer.
Love All Languages
Learn languages that follow different idioms and paradigms.
Consider also learning some “dead” languages that are no longer commonly used, to understand the history of your craft.
A good programmer knows many languages, and multiple idioms, broadening their palette of solutions. It improves the code they write.
Working with your programming language is a relationship you have to work at each day.
To write the best code in a language, you should commit to its styles and idioms rather than force your own upon it.
Good programmers are good communicators. They talk, write, code, listen, and read well.
Don’t expect to become a language master overnight, and don’t get frustrated whilst you work at it.
Concentrate effort on the most important things first. What is most urgent, or will produce the most value?
If you do something often, make the computer do it for you. Automate it with a script.
Split large tasks up into a series of smaller, well-understood tasks. You will be able to judge progress through these more accurately.
Make sure you define “done.”
If you can’t tell when it’s done, then you shouldn’t start it.
Use tests written in code to define when your code is complete and working.
Don’t do more work than necessary. Work until you’re “done.” Then stop.
When facing a problem, make sure you’ve considered more than one approach to solve it. Only then should you start working on it.
Purposefully place yourself beside excellent programmers.
More comments do not necessarily make your code better. Communicative code does not need extra commentary to prop it up.
Learn about development methodologies, trends, manifestos, and fads.

If you found this post helpful, please share it so that others can find it. You can follow me on GitHub and LinkedIn. If you have any ideas and improvements feel free to share them with me.

_Happy coding! _💪

Programming revolves around these 3 things

Sadick — Tue, 17 Jul 2018 06:30:01 +0000

When you think about programming you often feel that there is a lot more in that space. But if you look at it carefully programming revolves around these 3 things.

Input

Input involves getting data from some source. It might sensors, keyboard or any source. You might have a program that gets user input via a keyboard and another one that gets data via a file or URL. For your program to be useful you must provide it some data to work on (from any source).

Processing

Once data is in your program you have to process it in a meaningful way to solve your problem. The processing may involve, doing some arithmetic, making decisions based on certain conditions and looping through some things and performing actions on them.

Output

After the processing on the data you expect your program to give you some kind of feedback. That feedback is what output is. It might give the feedback by displaying something on your monitor or by performing another visible action like maybe shutting down a computer or moving the arm of a robot.The feedback you get is dependent on what you want to achieve.

A javascript story

Sadick — Mon, 09 Jul 2018 05:24:37 +0000

Five modern javascript developers were locked in a room and told to build a single page web app without using any framework. We don't know what happened but when we came back they were long gone.

Building deploy ready PHP apps

Sadick — Sun, 08 Jul 2018 12:15:18 +0000

What does deploy ready even mean.
It means that your application should be able to be deployed in any environment without changing the application code.

To make sure your application is deploy ready, things that can change between deploys(staging, alpha or production) should not be hard coded in your app.

I know you have come across or even written code like the one below while trying to make a database connection.

class Database
{
    public function connect($host, $user, $password)
    {
        $pdo = new PDO("mysql:host=$host;dbname=myDB", $user, $password);
        return $pdo;
    }
}

$db = new Database();
$db->connect("localhost", "root", "password");

There are two things wrong with the above approach:

You are hard-coding and exposing your database login credentials, which is just insecure
When you deploy your app to other environments you have to edit the connection code so that connection doesn't fail (unless that environment has the exact config)

To remedy the above code, you need a way to supply the credentials without hard coding them. This is achievable by using environment variables.
An environment variable is a dynamic-named value that can affect the way running processes will behave on a computer. In your case the dynamic value would be database username, address, password

Setting the environment variables

If you own the server you will be deploying to you can set the environment variables as below.

On windows server

setx DB_NAME test
setx DB_HOST localhost
setx DB_PASSWORD password

On ubuntu server

Open a terminal (by pressing CtrlAltT)
sudo -H gedit /etc/environment
Type your password
Edit the text file just opened:

DB_NAME=test
DB_HOST=localhost
DB_PASSWORD=password

Save, then logout and log back in for the changes to take effect.

Having set the environment variables you can now change your code to use the variables instead of hard coding.

$env = getenv();

$user = $env['DB_USER'];
$password = $env['DB_PASSWORD'];
$host = $env['HOST'];

$db = new Database();
$db->connect($host, $user, $password);

For those using a shared server with Apache. You will need to have an .htaccess file on the root folder. Normally public_html.
To set the environment variables, add the following into the file

SetEnv DB_USER your_production_db_user
SetEnv DB_PASSWORD your_production_db_password
SetEnv DB_NAME your_prodution_db_name

This sets the variables to the server. This has one drawback since getenv() only gets system environment variables. To remedy this you can merge both getenv() and $_SERVER to one array.

$env = array_merge(getenv(), $_SERVER);

I try as much as possible to avoid setting environment variables on my development machine, coz i just have so much going on on my machine. I What i normally do is have defaults in case the environment variable are not found on.

$user = $env['DB_USER'] ?? 'root';
$password = $env['DB_PASSWORD'] ?? 'password';
$host = $env['HOST'] ?? 'locahost';

Now that you have done that deploying comes very easy as you don't have to change anything in your code to make connection to a database. And you are also not exposing your database credentials.

The not so secret life of Provider in Redux

Sadick — Mon, 02 Jul 2018 12:50:17 +0000

I have always asked myself what the <Provider> does and why it is a neccessity while using redux.
How does react-redux make it possible for me to access my store objects.

My inquisitive nature led me to the react redux codebase. I expected to find a large compilcated <Provider> component, but to my suprise that wasn't the case.

I have ommited some code for readability sake.

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

class Provider extends React.Component {
  constructor(props, context) {
    super(props, context);
    this.store = props.store;
  }
  getChildContext() {
    return { store: this.store };
  }
  render() {
    return this.props.children;
  }
}
Provider.childContextTypes = {
  store: PropTypes.object
};

export default Provider;

What is the Provider doing

Provider makes use react's context api. Context provides a way to pass data through the component tree without having to pass props down manually at every level.

The provider makes store accessible to its child components via the getChildContext method. Therefore its children can access the store with props.context.store.

const Child = ({props}) => {
  console.log(props.context.store)
  return <div>child</div>
}

Now Child can have access to the store without us passing it down explicitly

<Provider store={store}>
  <Child/>
</Provider>

Also note the childContextTypes that is defined on the provider class. This is needed so that react can know the shape of data we are sharing via the context.

This is how the react-redux connect function is able to get our store objects. Below is a simplified version of the connect.


function connect(mapStateToProps, mapDispatchToProps) {
  return function(Component) {
    class App extends React.Component {
      constructor(props, context) {
        super(props, context);
        this.state = context.store.getState();
      }
      render() {
        return <Component {...this.state}/>
      }
    }
    App.contextTypes = {
      state: PropTypes.object
    };
    return App;
  };
}