profile
viewpoint
Jake LeBoeuf jakeleboeuf LeBoeuf Interactive Charleston, SC jakeleboeuf.com Senior Software Engineer @GiveCrypto

jakeleboeuf/contributor 19

A simple Node.js module to add git contributors to your package.json.

jakeleboeuf/ember-cli-bodymovin 7

A little Ember.js addon to handle svg/canvas animations from After Effects, using Bodymovin.

jakeleboeuf/campaign-scraper 3

An API for your indiegogo campaigns.

jakeleboeuf/angular-seed 0

Seed project for angular apps.

jakeleboeuf/angular.js 0

HTML enhanced for web apps

jakeleboeuf/animate-sass 0

A Sassy version of Dan Eden's Animate.css

jakeleboeuf/autoprefixer 0

Parse CSS and add vendor prefixes to rules by Can I Use

jakeleboeuf/codeclimate-tslint 0

Code Climate TSLint-Engine

jakeleboeuf/code_samples 0

Code Samples Repo

jakeleboeuf/colour-schemes 0

Sublime Text 2 Themes (textmate) created by Dayle Rees.

fork mathieudutour/DefinitelyTyped

The repository for high quality TypeScript type definitions.

fork in 4 hours

created repositoryjlengstorf/next-minimal-setup

created time in 12 hours

startedgeerlingguy/pi-webcam

started time in a day

created repositorysindresorhus/nano-queue

Tiny queue data structure

created time in a day

created repositoryjlengstorf/sanity-next-mdx

small demo showing how to store MDX in Sanity.io and display it in Next.js

created time in 2 days

startednetlify/explorers

started time in 2 days

MemberEvent
MemberEvent

startedprojectcalico/calico

started time in 3 days

PR opened reactjs/rfcs

RFC: contextFor
+104 -0

0 comment

1 changed file

pr created time in 3 days

startedmlflow/mlflow

started time in 3 days

pull request commentreactjs/rfcs

useMutableSource

Does it deopt "always" or only in the (potentially rare) case when a mutable source changes during an update/render

Only when a source changes during an update/render.

Note that if something is paused such as with startTransition, or possible future features like staggering animations this might not be such a short time span. It can be many seconds.

Sorry Seb, does "it can be many seconds" here mean that the update\render can be many seconds?

bvaughn

comment created time in 3 days

pull request commentreactjs/rfcs

useMutableSource

We have some other ideas for mutable multi-version stores that might prove useful for systems that want to provide full future compatibility

Looking forward to this.

bvaughn

comment created time in 3 days

startedIMRZ/tww2-campaign-editor

started time in 3 days

pull request commentreactjs/rfcs

useMutableSource

it’s likely easier to build a multi-version atom that can support some new api. A multi-version api can get full fidelity but requires some underlying support at the source to handle multiple versions. Similar to transactional databases.

this does sound like what I'm looking for.

I was also wondering if we could achieve something here via scheduling. Could a mutableSource offer a way to enqueue a function in which we can "safely" update the state? So that our state can live outside React (defined before any React root has been mounted, and used independently of any React views), but we let the React scheduler handle timing of updates?

Example usage might be a local in-memory db that we update from incoming websocket messages. Messages come in async anyway, and our app won't care or know if the timing is slightly adjusted so long as order is respected. Something like:

const myWebsocketConnection = {..}
const myMemoryDB = atom()
const mutableSource = createMutableSource(inMemoryDB, getAtomValue)

myWebsocketConnection.onmessage = (message) => {
  // could a mutable source let us schedule a function
  // in which we can safely update its state?
  mutableSource.schedule(() => myMemoryDB.swap(addMessageFn, message))
}
bvaughn

comment created time in 3 days

fork sindresorhus/npmhub

:mag_right: A browser extension for exploring npm dependencies on GitHub repos

https://npmhub.org

fork in 3 days

pull request commentreactjs/rfcs

useMutableSource

Perhaps I am being confused by the language here - do you mean "don't use useMutableSource at all", or "use useMutableSource only with immutable data structures"?

useMutableSource if you have either mutable data structures or if you have mutable atom where that atom lives outside React.

If you have immutable data, storing it in useState or useReducer is preferable because it will just work with everything.

bvaughn

comment created time in 3 days

pull request commentreactjs/rfcs

useMutableSource

Does it deopt "always" or only in the (potentially rare) case when a mutable source changes during an update/render

Only when a source changes during an update/render.

Note that if something is paused such as with startTransition, or possible future features like staggering animations this might not be such a short time span. It can be many seconds.

If you use something like media queries or location.href it might be fine since it might be unlikely to happen very often at the same time.

Similarly if you use it to implement a data fetching library it might work better because you only get new data occasionally and round trips are slow which throttles the likelihood.

It’s more that if you use this to effectively replace all state in React you might have an increased likelihood to hit these pretty much all the time.

So if you’re implementing a state library that is meant to completely replace usages of useState, you might have a bad time.

I’m not sure how ClojureScript stores the atom. If it’s stored outside React then it’s a mutable field and that mutable field suffers from this.

However if your api is immutable it’s likely easier to build a multi-version atom that can support some new api.

A multi-version api can get full fidelity but requires some underlying support at the source to handle multiple versions. Similar to transactional databases.

bvaughn

comment created time in 3 days

pull request commentreactjs/rfcs

useMutableSource

@orestis As long as you're keeping your data in React and updating it immutably with state, you shouldn't need useMutableSource.

bvaughn

comment created time in 3 days

pull request commentreactjs/rfcs

useMutableSource

Thanks @sebmarkbage for chiming in. What is the correct way then to handle global data that is actually immutable? I’m working with ClojureScript and I’ve implemented a store by generally copying the use-subscription package approach which is mainly backed by a useState hook.

I was under the impression that useMutableSource was the correct way for concurrent mode but you’re saying that I should keep using plain useState if my data in there is immutable?

bvaughn

comment created time in 3 days

pull request commentreactjs/rfcs

useMutableSource

it will still deopt all concurrent mode features when it happens

Does it deopt "always" or only in the (potentially rare) case when a mutable source changes during an update/render?

in the current experimental releases the only way to be fully compatible is by using immutable data

Perhaps I am being confused by the language here - do you mean "don't use useMutableSource at all", or "use useMutableSource only with immutable data structures"?

My particular use case remains - how to use a ClojureScript atom with React. An atom is a kind of pointer to an immutable data structure - so the value we read at any given time (ie. what we can return from getSnapshot) is immutable, but the parent atom/source can be swapped to point to a new immutable thing at any time.

Or, a non-ClojureScript example - browser state like window.location.href - it's external state that can potentially change at any time, with an immutable (string) value, that we want to depend on from React views. Is useMutableSource an appropriate approach for that?

bvaughn

comment created time in 3 days

pull request commentreactjs/rfcs

useMutableSource

Since it might be buried a bit here. useMutableSource makes it so that you don’t have semantic breakages due to tearing. However it will deopt all concurrent mode features when it happens. So it’s not compatible with new features.

It’s not recommended for new tooling that wants to be concurrent mode compatible. It’s for legacy compatibility.

We have some other ideas for mutable multi-version stores that might prove useful for systems that want to provide full future compatibility but in the current experimental releases the only way to be fully compatible is by using immutable data.

bvaughn

comment created time in 3 days

startedfregante/ghat

started time in 3 days

created repositorysindresorhus/p-state

Inspect the state of a promise

created time in 3 days

starteddersvenhesse/awesome-scriptable

started time in 4 days

startedandrewosh/hypercopy

started time in 5 days

startedericclemmons/polydev

started time in 6 days

created repositorylearnwithjason/jamstack-databases-hasura

created time in 6 days

fork maddox/alpine-nginx-nodejs

A tiny docker image for JavaScript with major stream workflow CI (like jenkins)

https://hub.docker.com/r/hoosin/alpine-nginx-nodejs

fork in 6 days

startedantonioru/beautiful-react-diagrams

started time in 6 days

more