| window.customElements.define("elm-portal", class extends HTMLElement { | |
| // Base custom element stuff | |
| constructor() { | |
| super(); | |
| this._targetNode = document.createElement('div'); | |
| } | |
| connectedCallback() { | |
| document.querySelector(this.getAttribute("data-target-selector")).appendChild(this._targetNode); | |
| } |
You can see the end result in this ellie. It displays a smooth removal of the clicked items. You can also remove some items from the beginning or the end.
https://ellie-app.com/cvCV93KgD56a1
An updated ellie with improved performance. This gist was not yet updated with all changes made in this version. Only the article text is somewhat updated.
Back in December 2017, I started working on something I called Elmish-Wasm, which was just an experimental repo to compile something Elm-like to Wasm. I made some progress, but the helpful people I talked and I came to the conclusion that most of what I had so far (Haskell and Regex to interpret .elm files into rudimentary wasm) was something the Elm compiler and the Elm AST already did. Writing that code was a lot of fun, but maybe not the most valuable way to explore Elm and WebAssembly. Before jumping back into this project I would like to record the important facts and questions related to compiling Elm to Wasm.
A lot of people talk about Web Assembly as if its C++ that runs in the browser. Thats not the case. This belief must come from that fact that C can currently compile to web assembly. Wasm is human-unreadable bytecode. There is a human-readable version of wasm, called wat. It looks like this..
;; A function that adds two numbe
| // https://raw.githubusercontent.com/donnut/typescript-ramda/master/ramda.d.ts | |
| // https://raw.githubusercontent.com/DefinitelyTyped/DefinitelyTyped/master/lodash/lodash.d.ts | |
| declare namespace fp { | |
| interface Dictionary<T> { | |
| [index: string]: T; | |
| } | |
| interface CurriedFunction1<T1, R> { |
I am moving this gist to a github repo so more people can contribute to it. Also, it makes it easier for me to version control.
Please go to - https://github.com/praveenpuglia/shadow-dom-in-depth for latest version of this document. Also, if you find the document useful, please shower your love, go ⭐️ it. :)
Heads Up! It's all about the V1 Spec.
In a nutshell, Shadow DOM enables local scoping for HTML & CSS.
| // Check if rectangle a contains rectangle b | |
| // Each object (a and b) should have 2 properties to represent the | |
| // top-left corner (x1, y1) and 2 for the bottom-right corner (x2, y2). | |
| function contains(a, b) { | |
| return !( | |
| b.x1 < a.x1 || | |
| b.y1 < a.y1 || | |
| b.x2 > a.x2 || | |
| b.y2 > a.y2 | |
| ); |
| #!/bin/sh | |
| echo Install all AppStore Apps at first! | |
| # no solution to automate AppStore installs | |
| read -p "Press any key to continue... " -n1 -s | |
| echo '\n' | |
| echo Install and Set San Francisco as System Font | |
| ruby -e "$(curl -fsSL https://raw.github.com/wellsriley/YosemiteSanFranciscoFont/master/install)" | |
| echo Install Homebrew, Postgres, wget and cask | |
| ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)" |
| find `pwd` -type d -maxdepth 3 -name 'node_modules' | xargs -n 1 tmutil addexclusion |
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
