Revise Readme (fixes #170)

[bjoluc]

• Add motivation section (Add an "About" section to the readme #170)
• Add TypeScript examples (Fix #165 #176, Support strict type checking #177)
• Make installation code blocks expandable
• Migrate connected Page components to functional components
• Group tips and examples in a Tips and Tricks section
• Some grammar & style improvements
• Remove outdated typings reference in Resources section
• Add npm package badge
• Remove deprecated Container notice

I didn't find time to walk through the Tips and Tricks section yet – I think it could profit from TS examples as well.

[bjoluc]

Although it is possible to create server or client specific logic in both makeStore and getInitialProps, I highly recommend that they do not have different behavior. This may cause errors and checksum mismatches which in turn will ruin the whole purpose of server rendering.

@kirill-konshin I don't really understand that part, especially the second sentence. Maybe I don't understand the whole purpose of SSR then :D
I think there are many real-world situations in which custom conditional logic in makeStore is a very good thing (e.g. redux-persist, redux-dev-middleware), without breaking anything. What situation did you have in mind when you wrote this?

[kirill-konshin]

The problem here was that if makeStore adds something that will cause state to change (from persistence) you may end up in a situation when React cannot apply itself on server-generated markup and has to re-render the entire page. Which means you defeated purpose of SSR — to render content faster and in one pass.

[bjoluc]

Oh, I see. Although that would require some serious state changes with a great impact on the UI. Otherwise, AFAIK, react would only update DOM elements that require an update.
SSR is also very useful for SEO. So I wouldn't call it "the whole purpose"...

What about "While you can create server or client specific logic in both makeStore and getInitialProps, you should be careful with that. Differences between client and server state may cause DOM modifications on client-side renders that mitigate the advantage of SSR."? That seems more precise to me. What do you think?

[kirill-konshin]

Yes, this is a good wording for the case. React sometimes is not as smart and if checksum does not match it rerenders everything. Which means all performance optimizations are wasted. For SEO case it’s less impactful.