| if (!('trimStart' in String.prototype)) String.prototype.trimStart = String.prototype.trimLeft; | |
| if (!('trimEnd' in String.prototype)) String.prototype.trimEnd = String.prototype.trimRight; | |
| if (!('forEach' in NodeList.prototype)) NodeList.prototype.forEach = [].forEach; | |
| if (!('description' in Symbol.prototype)) { | |
| Object.defineProperty(Symbol.prototype, 'description', { | |
| get() { return /\((.+)\)/.exec(this)[1] } | |
| }); | |
| } |
Polyfill dynamic import() in all ES Modules-supporting browsers.
Drop this polyfill into your page: https://github.com/GoogleChromeLabs/dynamic-import-polyfill
... then add the Babel transform:
import dynamicImportPolyfill from 'dynamic-import-polyfill';
Oh boy :) cracks knuckles tl;dr no, also I overlooked so much, thanks for pointing this out.
The minified JS I linked to is every polyfill that @babel/present-env would provide. The recommended distribution of these polyfills is not the module I linked (@babel/polyfill), but instead via @babel/preset-env. Regardless, they both use the polyfills as defined by core-js. You can see that the polyfills module has a standard bundling and minifying script: https://github.com/babel/babel/blob/fced5cea430cc00e916876b663a8d2a84a5dad1f/packages/babel-polyfill/scripts/build-dist.sh, which is what I linked to before. The question is: does the pattern I'm looking for hold for these core-js polyfills regardless of the minifier used? Additionally: where does this pattern come from? I'll focus on that first.
To further complicate, there's core-js@2 and core-js@3, and both seem to be used (or at leas
| const Component = require('preact/compat').Component; | |
| const AUTOBIND_BLACKLIST = { | |
| constructor: 1, | |
| render: 1, | |
| shouldComponentUpdate: 1, | |
| componentWillReceiveProps: 1, | |
| componentWillUpdate: 1, | |
| componentDidUpdate: 1, | |
| componentWillMount: 1, |
Most JavaScript developers love making modern applications, with our new language features and latest libraries making our life easier, but has any one ever actually wondered if this ever impacts our users.
We are dealing with abstractions, abstractions are trying to cover a general use case which could not be conforming to yours. Some are over-engineered in ways one can't possibly comprehend, use cases that will never be reached by middle sized applications. Some of these over
A proof-of-concept Python code rewriter, transforming JavaScript-like tagged template strings (tag"foo{1+2}bar") to plain function calls (tag(["foo", "bar"], [1+2])).
Note that the code requires tagged version 0.0.2 or higher.
You can use ./encoder.py file to transform STDIN input to STDOUT:
$ python3 encoder.py < example_input.py
Combines all bare imports (npm module imports) into a single packd-es import.
Input:
import { h, render } from 'preact@next';
import { useState } from 'preact@next/hooks';
import { html } from 'htm/preact';
render(h(() => html`<a />`), document.body);
| from htm import htm | |
| from hyperpython import h | |
| from inspect import signature, Parameter | |
| @htm | |
| def html(tag, props, children): | |
| if callable(tag): | |
| return relaxed_call(tag, children=children, **props) | |
| return h(tag, props, children) |