Add a section about Types global namespace

[piotrwitek]

We would need a new section explaining how I designed cross-cutting Types global project namespace to be easily reused across the project as a module encapsulating all the types in the application.
I leveraged the inversion of control principle, so instead of defining all the types in one place (in Types module, it's the responsibility of modules (which are owners of that particular type annotations) to extend the Types namespace.

The main benefits are:

• simplicity to extend
• easy maintenance - for instance when you remove some application module you also delete the extension point because it's colocated with the module
• nicely and cleanly imported in type consumers

import Types from 'Types';
// reducer(state: Types.RootState , action: Types.RootAction) => ...
// mapDispatchToProps(dispatch: Dispatch<Types.RootAction>)
// Epic<Types.RootAction, Types.RootState, Types.Services>

---

IssueHunt Summary

Backers (Total: $40.00)

• issuehunt ($40.00)

Submitted pull Requests

• #226 docs: add section explaining Types global namespace usage (#97)
• #270 docs: add Types global namespace section
• #288 docs: explain Types global namespace
• #345 Fix #97: Add a section about Types global namespace

---

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[IssueHuntBot]

@issuehuntfest has funded $20.00 to this issue. See it on IssueHunt

[IssueHuntBot]

@IssueHunt has funded $20.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.