Google could easily adjust their ranking algorithm to better reward non-AMP pages (which they've obviously already crawled) which they know are 1) below say 75 KB and 2) contain a limited number of resources to fetch. But instead of doing that, they choose to attempt to strongarm everyone into using AMP.
What you're describing is called "replication" in Unreal Engine. It helps tremendously with writing declarative code, and I've found it to be exceptionally powerful and predictable.
I love this architecture so much that I brought it into the world of React and Redux a couple years ago (see https://github.com/loggur/react-redux-provide and https://github.com/loggur/redux-replicate). Dan Abramov and the ReactTraining guys immediately shit on it for some odd reason (I probably did a horrible job of explaining it), saying it wouldn't work in the real world, but I (and my team) have been using it very successfully... in the real world.
With that said, I do need to update the docs and improve some internals (and remove some unnecessary stuff like query handling), but there's only so much time in a day. :)
I'm a full stack expert with years of experience ranging from modern web dev to robotics & embedded systems to gaming engines. Passionate about great tools and great design and I enjoy pushing technology to the next level.
I'm a full stack expert with years of experience ranging from modern web dev to robotics & embedded systems to gaming engines. Passionate about great tools and great design and I enjoy pushing technology to the next level.
These self-driving cars are a good start though. It makes sense - to me at least - that more self-driving cars on the road means fewer accidents. Imagine if nearly every vehicle was autonomous and wirelessly networked with other nearby vehicles. We'd see little to no accidents, assuming everything is secure and working correctly.
This allows you to encapsulate all of your Redux actions/reducers/etc into standalone "providers". It decouples pretty much all of your React components (UI) from your Redux logic (models/controllers), which maximually separates your concerns and makes it trivial to reuse anything anywhere. It also allows you to instantly swap databases and/or websocket implementations.
I believe most of what it's doing under the hood is explained in the article. Sorry if it isn't 100% clear.
Short version:
- A provider has its own store (or it can share a store with other providers if you need it to).
- When you have a `propType` matching a provider's `actions`, those actions are automatically mapped to the store's dispatcher; so when you call `this.props.someAction`, it's essentially calling `provider.store.dispatch(provider.actions.someAction())`.
- And when you have a `propType` matching a provider's `reducers`, that component will always have the latest state of that reducer.
Without the `@provide` decorator, you would just `export default provide(SomeComponent)`. I've opted to use the ES7 decorator because it's cleaner, more concise, and immediately apparent.
It was already pretty clear, but your point-form explanation makes it even more clear. Somehow, I imagined there was more "magic" going on behind the scenes, but it's actually just matching this.props with actions and reducers.
This is a really neat idea, though I can imagine there might be some problems name conflicts for larger applications... still, it totally looks like something I will play with in the comping weeks. Thx for the writup and the above concise explanation.
