Echo JS 0.11.0

IMHO we should really think twice before messing up Stateless/Effect-Free Functional Components with hooks.

To pick up the example in the readme: In original react-redux you probably would create a ProfileStateless Component and a ProfileConnected Component. ProfileStateless as Stateless Functional Component and ProfileConnected as a Component which is connected to the redux store. The beauty of the ProfileStateless Component is that it's easy to test and that it can be also re-used outside of the redux context. Also, someone reading the code of the ProfileStateless function directly sees what the input of the Component is, by checking the props. IMHO we will loose these advantages if we now start using hooks everywhere. That being said, I do see benefits of using hooks in Container Components.

The solution to question 4 part 2 is also a bit odd. Left a comment about that here: https://medium.com/@simon.kusterer/the-suggested-second-solution-of-question-4is-quite-odd-imo-3891ff46bfd6

Cool idea in general!

One suggestion though: As someone who does not know you guys, it is hard do know what kind of JS expertise you have. Maybe that could be made more clear in the readme. That would build up more trust IMO. Because otherwise it is quite hard to determine the value of the answers and how high the likelihood is that they are "correct" (although "correct" can of course often be subjective).

I just mean that by optimizing your app for AWS Lambda and using surrounding services like DynamoDB, S3, API Gateway, etc. it can/may be hard to later on move your app to some other platform.

For example, if you would instead split your app up in multiple docker containers, using open source technologies like expressjs, postgres and ngnix, it should be quite easy (or at least easier) to move your app to another platform which supports containers.

To be clear, I'm not saying that you shouldn't use AWS Lambda at all, just don't blindly follow the hype and carefully evaluate if it solves a problem you're having.

Before switching to AWS Lambda keep a few things in mind:

* A lambda function has a maximal execution timeout of 5 minutes
* API Gateway has a timeout of 30 seconds for incoming requests
* Because of those limits you probably won't be able to use Websockets
* You are totally binding yourself to Amazon services
* If your app has periods where it doesn't get much incoming traffic then cold starts might become a problem

If all that isn't a problem for you and your app has that much traffic, then go for it ;)

So, if I understand it correctly, the suspending stuff basically boils down to:

If you throw a promise in your render method then React will abort rendering that component, wait for that promise to fulfill and then render the component again.

And the createFetcher is a helper around this which prevents the promise from being thrown again a second time.

Catching the promise is probably done with the help of error bounderies.

To be honest, TypeScript feels more like a hack to me. If you want types then just use a programming language which has types from the ground up and compile it to JavaScript. Either go all the way down or don't do it at all. Feel free to downvote ;)

nice :) but you really should add some tests.

Sounds like an interesting pattern in general and I would love to hear the opinion from somebody who used this already in some bigger projects.

Although I am a bit afraid that this results in some deep nested component structure. For example, say you have a Page component, inside that a Sidebar component, inside that a Navigation component, inside that a List component, inside that Item-Group components and inside that you have the actual Item components. This would already be like 5 levels of nesting. Now add Routing components etc. to the mix...

A nice use case for portals (other than modals, dropdowns etc.) could be dynamic widgets on websites (like the typical wordpress / drupal websites). For example, if you have dynamic widgets which are spread across the page, but somehow belong together. So you could have a widget for the search-field in the header of the page and a widget for the search-results in the content area and both would be part of the same react app. Or a table with filters, where the table and the filters are two separate widgets.