Echo JS 0.11.0

<~>

xat comments

xat 40 days ago. link 2 points
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
xat 42 days ago. link 1 point
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).
xat 56 days ago. link 2 points
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.
xat 57 days ago. link 4 points
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 ;)
xat 87 days ago. link 5 points
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.
xat 114 days ago. link 2 points
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 ;)
xat 216 days ago. link 4 points
nice :) but you really should add some tests.
xat 236 days ago. link 2 points
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...
xat 242 days ago. link 5 points
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.
xat 267 days ago. link 1 point
Agreed. I mostly keep the state in some container components and only use redux if it's really needed. That approach works just fine.
[more]