Not OP and I don't have any resources for you, but I spent a while playing around with Polymer in the very early (0.3) stages, and was one of the first internal Google customers for them.
I found that once you have web components, there's nothing stopping you from representing your entire webapp's UI in terms of semantic elements only. For example, a HN comment thread could look something like this:
<hn-thread
title="Ask HN: What are the cons of Google Polymer?"
votes="47"
comments="46"
posted="20160509T12:12:00">
<hn-comment author="sshumaker" posted="20160509T14:12:00">
Disclaimer: I led development of gaming.youtube.com...
<hn-comment author="justjco" posted="20160509T14:40:00">
I found you don't really need Redux if you follow the "DOM is your API" paradigm....
<hn-comment ...></hn-comment>
</hn-comment>
<hn-comment author="torgoguys" posted="20160509T14:56:00">
You answered the question asked, but I'm also curious as to what you liked about it for that project.
</hn-comment>
</hn-comment>
</hn-thread>
All of the details about how to present a <hn-thread> or <hn-comment> are encapsulated in the definition of the custom element, and you only specify the data that changes between each one. Similarly, you could define methods on <hn-comment> that pop up a comment box when you hit "reply", for example, and this also drops out of the light DOM tree.
When you do it this way, your DOM becomes basically isomorphic to what you would write in your Redux state or send in a JSON response. You could, in fact, write a trivial helper to convert between JSON and DOM, but there isn't really a need when you could just send HTML down the wire.
This sounds quite a lot to React components. Cool to see different technologies agree on the benefits of componentized UI!
That said I believe Redux is not so much about representing the state tree as it is about making its mutations centralized and predictable (the same actions, replayed, will always produce the same state). While a componentized tree often helps ensure this, it is less of a case when the state shape itself doesn’t neatly match the rendered component tree. This is the use case where Redux, in my opinion, offers some options.
nostrademons|9 years ago
I found that once you have web components, there's nothing stopping you from representing your entire webapp's UI in terms of semantic elements only. For example, a HN comment thread could look something like this:
All of the details about how to present a <hn-thread> or <hn-comment> are encapsulated in the definition of the custom element, and you only specify the data that changes between each one. Similarly, you could define methods on <hn-comment> that pop up a comment box when you hit "reply", for example, and this also drops out of the light DOM tree.When you do it this way, your DOM becomes basically isomorphic to what you would write in your Redux state or send in a JSON response. You could, in fact, write a trivial helper to convert between JSON and DOM, but there isn't really a need when you could just send HTML down the wire.
danabramov|9 years ago
That said I believe Redux is not so much about representing the state tree as it is about making its mutations centralized and predictable (the same actions, replayed, will always produce the same state). While a componentized tree often helps ensure this, it is less of a case when the state shape itself doesn’t neatly match the rendered component tree. This is the use case where Redux, in my opinion, offers some options.
spankalee|9 years ago
nightwolf|9 years ago
kaycebasques|9 years ago
> What does that mean, exactly? Do you have any resources you could link to?
Check out the "Thinking in Polymer" talk from Polymer Summit 2015: https://www.youtube.com/watch?v=ZDjiUmx51y8
Specifically talks about "the DOM is your API" at 0:49 --> https://youtu.be/ZDjiUmx51y8?t=50
disclaimer: technical writer for polymer