A few conversations have circled around user-side structural profiling. For context, see React PR #7549: Show React events in the timeline when ReactPerf is active
One particular concern is the measurement overhead. This gist has a benchmarking script (measure.js) for evaluating overhead and initial results.
Runs about 0.65µs per mark() call. Naturally, that's ~= an overhead of 1ms for 1500 mark()s.
| /** | |
| * Fancy ID generator that creates 20-character string identifiers with the following properties: | |
| * | |
| * 1. They're based on timestamp so that they sort *after* any existing ids. | |
| * 2. They contain 72-bits of random data after the timestamp so that IDs won't collide with other clients' IDs. | |
| * 3. They sort *lexicographically* (so the timestamp is converted to characters that will sort properly). | |
| * 4. They're monotonically increasing. Even if you generate more than one in the same timestamp, the | |
| * latter ones will sort after the former ones. We do this by using the previous random bits | |
| * but "incrementing" them by 1 (only in the case of a timestamp collision). | |
| */ |
By: @BTroncone
Also check out my lesson @ngrx/store in 10 minutes on egghead.io!
Update: Non-middleware examples have been updated to ngrx/store v2. More coming soon!
Table of Contents
Since Twitter doesn't have an edit button, it's a suitable host for JavaScript modules.
Source tweet: https://twitter.com/rauchg/status/712799807073419264
const leftPad = await requireFromTwitter('712799807073419264');
| function go() { | |
| var userId = prompt('Username?', 'Guest'); | |
| checkIfUserExists(userId); | |
| } | |
| var USERS_LOCATION = 'https://SampleChat.firebaseIO-demo.com/users'; | |
| function userExistsCallback(userId, exists) { | |
| if (exists) { | |
| alert('user ' + userId + ' exists!'); |
| // assumes you add a timestamp field to each record (see Firebase.ServerValue.TIMESTAMP) | |
| // pros: fast and done server-side (less bandwidth, faster response), simple | |
| // cons: a few bytes on each record for the timestamp | |
| var ref = new Firebase(...); | |
| ref.orderByChild('timestamp').startAt(Date.now()).on('child_added', function(snapshot) { | |
| console.log('new record', snap.key()); | |
| }); |
This utility script deploy a single local file to an existing Firebase Hosting site. Other files that are already deployed are left unmodified.
The difference with firebase deploy is that this script does not require you to have a local snapshot of all hosted files,
you just need the one file that you want to add/update.
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <style> | |
| /* How to select a range of children | |
| * (Here, 3rd-7th children, inclusive): | |
| */ | |
| ul li:nth-child(n+3):nth-child(-n+7) { | |
| outline: 1px solid #0f0; | |
| } |
Domenic's blöcks proposal outlines a way to conveniently define functions that run in another worker/worklet as an inline, non-capturing scope, function body.
Blöcks as proposed have a few open questions and lack a few features that could generalize them to more use cases and with more practical ergonomics.
| function getParent(snapshot) { | |
| // You can get the reference (A Firebase object) from a snapshot | |
| // using .ref(). | |
| var ref = snapshot.ref(); | |
| // Now simply find the parent and return the name. | |
| return ref.parent().name(); | |
| } | |
| var testRef = new Firebase("https://example.firebaseIO-demo.com/foo/bar"); | |
| testRef.once("value", function(snapshot) { |
