Original Letter | Look-Alike(s) |
---|---|
a | а ạ ą ä à á ą |
c | с ƈ ċ |
d | ԁ ɗ |
e | е ẹ ė é è |
g | ġ |
h | һ |
using OpenTelemetry; | |
using OpenTelemetry.Logs; | |
using OpenTelemetry.Resources; | |
using OpenTelemetry.Trace; | |
var builder = WebApplication.CreateBuilder(args); | |
var app = builder.Build(); | |
var appResourceBuilder = ResourceBuilder.CreateDefault() | |
.AddService(serviceName: Telemetry.ServiceName, serviceVersion: Telemetry.ServiceVersion); |
/* | |
* Stripe WebGl Gradient Animation | |
* All Credits to Stripe.com | |
* ScrollObserver functionality to disable animation when not scrolled into view has been disabled and | |
* commented out for now. | |
* https://kevinhufnagl.com | |
*/ |
tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.
A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.
But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.
How do we solve this with React?
These 'notes' were primarily intended for my own consumption but since there have been surprisingly many comments to it over the years I wanted to do some updates and clarifications. Thanks for all comments.
These instructions will require you to have connection to internet from your pi, WiFi, Ethernet or by some other means like a 3G USB dongle or something.
package main | |
import ( | |
"crypto/rand" | |
"encoding/base64" | |
"fmt" | |
"io" | |
"math/big" | |
) |
terminal:
npm i --save-dev rollup rollup-watch rollup-plugin-typescript typescript typings
npm i -S react react-dom
./node_modules/.bin/typings install react react-dom --save
mkdir src dist
touch src/index.tsx
/* | |
sample usage: | |
var path = getDomPath(element); | |
console.log(path.join(' > ')); | |
output: | |
body > section:eq(0) > div:eq(3) > section#content > section#firehose > div#firehoselist > article#firehose-46813651 > header > h2 > span#title-46813651 | |
taken from: | |
http://stackoverflow.com/questions/5728558/get-the-dom-path-of-the-clicked-a |
In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.
At the moment GraphQL allows 2 types of queries:
query
mutation
Reference implementation also adds the third type: subscription
. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.