| function logger(strings,...values) { | |
| var str = ""; | |
| for (let i = 0; i < strings.length; i++) { | |
| if (i > 0) { | |
| if (values[i-1] && typeof values[i-1] == "object") { | |
| if (values[i-1] instanceof Error) { | |
| if (values[i-1].stack) { | |
| str += values[i-1].stack; | |
| continue; | |
| } |
Bear with me while I think aloud about this (please comment there, not here!). Goals:
Let's start with a single store that is external to the component tree. Our top-level <App> component connects to it:
One of the biggest missed opportunities thus far with HTTP/2 ("H/2") is that we are not yet able to sunset WebSockets in favor of H/2. Web Sockets and H/2 both support multiplexing messages bi-directionally and can send both textual and binary data.
Server Sent Events ("SSE"), by contrast, are not bi-directional (they're a "server-push-only" channel) and binary data cannot be sent easily. They are, however, very simple to implement. Adding to the menagerie of options, RTCPeerConnection can also be used to signal data to applications in a low-latency (but potentially lossy) way.
Because H/2 [does not support the handshake (upgrade) that WebSockets use to negotiate a connection](https://daniel.haxx.se/blog/2016/06/15/no-websockets-
The code here captures some of the patterns I used in the "real estate" demo app discussed in my talk End to End Apps with Polymer from Polymer Summit 2017.
There are many ways to connect Redux to custom elements, and this demonstrates just one pattern. The most important aspects are to try and lazily-load as much of the otherwise global state management logic along with the components that need them (as shown via the lazyReducerEnhancer and addReducers calls in the connected components), and to consider the tradeoffs you make in terms of coupling components to the store.
The pattern shown here of creating a stateless component and then a subclass that connects it to the store addresses a potential desire to reuse app-level stateless components between more than one application context, so the subclass provides a degree of decoupling from the concrete store, at the expense of more boilerplate. If app com
| // UPDATE: In 2023, you should probably stop using this! The narrow version of Safari that | |
| // does not support `nomodule` is probably not being used anywhere. The code below is left | |
| // for posterity. | |
| /** | |
| * Safari 10.1 supports modules, but does not support the `nomodule` attribute - it will | |
| * load <script nomodule> anyway. This snippet solve this problem, but only for script | |
| * tags that load external code, e.g.: <script nomodule src="nomodule.js"></script> | |
| * | |
| * Again: this will **not** prevent inline script, e.g.: |
As the web component specs continue to be developed, there has been little information on how to test them.
In particular the /deep/ combinator has been deprecated in Shadow DOM 1.0. This is particularly painful since
most end-to-end testing frameworks rely on elements being discoverable by XPath or calls to querySelector.
Elements in Shadow DOM are selectable by neither.
Webdriver.io has the standard actions by selectors, but also allows browser executable scripts to return an element
| [alias] | |
| outdated = "!f() { bash -c 'diff -u <(git branch --no-merged master) <(git branch --contains master) | egrep \"^- \"'; }; f" | |
| update = "!f() { set -e; git checkout $1; git rebase master; git push -f origin $1; git checkout -; }; f" |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
Here's what I did to get things working.
Yep, over at: https://developer.apple.com