sophiebits Github contribution chart
sophiebits Github Stats
sophiebits Most Used Languages

Activity

13 Sep 2022

Sophiebits

[Beta] Expand useMemo documentation

Added:

  • Deep dive ("Memoizing individual JSX nodes")
  • Usage: Memoizing a function with a link to useCallback
  • Deep dive ("Does every value need to be memoized?")
  • Implied caching guarantees in the Reference
  • Troubleshooting: A component re-renders every time
  • Troubleshooting: Calling useMemo in a loop

Forked On 13 Sep 2022 at 01:25:27

Sophiebits

missing useMemo?
On 13 Sep 2022 at 01:25:27

Sophiebits

[Beta] Expand useMemo documentation

Added:

  • Deep dive ("Memoizing individual JSX nodes")
  • Usage: Memoizing a function with a link to useCallback
  • Deep dive ("Does every value need to be memoized?")
  • Implied caching guarantees in the Reference
  • Troubleshooting: A component re-renders every time
  • Troubleshooting: Calling useMemo in a loop

Merged On 13 Sep 2022 at 01:26:45

Sophiebits

Commented On 13 Sep 2022 at 01:26:45

Sophiebits

[Beta] Expand useMemo documentation

Added:

  • Deep dive ("Memoizing individual JSX nodes")
  • Usage: Memoizing a function with a link to useCallback
  • Deep dive ("Does every value need to be memoized?")
  • Implied caching guarantees in the Reference
  • Troubleshooting: A component re-renders every time
  • Troubleshooting: Calling useMemo in a loop

Merged On 13 Sep 2022 at 01:26:45

Sophiebits

Commented On 13 Sep 2022 at 01:26:45

Sophiebits

[Beta] Auto-expand on inline search

Chrome can do this with built-in <details> tag now.

Also it's better semantically anyway.

Forked On 09 Sep 2022 at 02:47:15

Sophiebits

Should this be on the summary? Won't this mean that any links in the children, say, won't work?
On 09 Sep 2022 at 02:47:15

Sophiebits

[Beta] Auto-expand on inline search

Chrome can do this with built-in <details> tag now.

Also it's better semantically anyway.

Forked On 09 Sep 2022 at 02:47:40

Sophiebits

(nit: shouldn't this be currentTarget for the hypothetical case of nested details tags?)
On 09 Sep 2022 at 02:47:40

Sophiebits

[Beta] Auto-expand on inline search

Chrome can do this with built-in <details> tag now.

Also it's better semantically anyway.

Merged On 09 Sep 2022 at 02:50:45

Sophiebits

Commented On 09 Sep 2022 at 02:50:45

Sophiebits

[Beta] Auto-expand on inline search

Chrome can do this with built-in <details> tag now.

Also it's better semantically anyway.

Merged On 09 Sep 2022 at 02:50:45

Sophiebits

Commented On 09 Sep 2022 at 02:50:45

Sophiebits

[Beta] Initial API doc for Suspense

This doesn't include everything but I think it's good enough for a start.

I didn't add any interactive examples yet because I want to use the use API, so I'll wait until that's documented.

Forked On 01 Sep 2022 at 05:15:38

Sophiebits

Mention useTransition for a loading indicator? Folks may think they don't want startTransition because there's no visual feedback.
On 01 Sep 2022 at 05:15:38

Sophiebits

[Beta] Initial API doc for Suspense

This doesn't include everything but I think it's good enough for a start.

I didn't add any interactive examples yet because I want to use the use API, so I'll wait until that's documented.

Merged On 01 Sep 2022 at 05:15:39

Sophiebits

Commented On 01 Sep 2022 at 05:15:39
Issue Comment

Sophiebits

Puzzle generation

Are the puzzle generation scripts open source? I was thinking about classifying puzzles based on their difficulty – eg distinguishing puzzles where you need to only lock known pieces from ones where you need to take notes about edges from ones where even more complex strategies are needed.

Forked On 18 Aug 2022 at 05:21:57

Sophiebits

My tentative plan (once I find time to finish it) is to write a program that uses human strategies I've enumerated to try to classify which puzzles require more advanced strategies than others.

Commented On 18 Aug 2022 at 05:21:57
Merge

Sophiebits

experimental_use(promise)

Based on #25074

Adds experimental support to Fiber for unwrapping the value of a promise inside a component. It is not yet implemented for Server Components, but that is planned.

If promise has already resolved, the value can be unwrapped "immediately" without showing a fallback. The trick we use to implement this is to yield to the main thread (literally suspending the work loop), wait for the microtask queue to drain, then check if the promise resolved in the meantime. If so, we can resume the last attempted fiber without unwinding the stack. This functionality was implemented in previous commits.

Another feature is that the promises do not need to be cached between attempts. Because we assume idempotent execution of components, React will track the promises that were used during the previous attempt and reuse the result. You shouldn't rely on this property, but during initial render it mostly just works. Updates are trickier, though, because if you used an uncached promise, we have no way of knowing whether the underlying data has changed, so we have to unwrap the promise every time. It will still work, but it's inefficient and can lead to unnecessary fallbacks if it happens during a discrete update.

When we implement this for Server Components, this will be less of an issue because there are no updates in that environment. However, it's still better for performance to cache data requests, so the same principles largely apply.

The intention is that this will eventually be the only supported way to suspend on arbitrary promises. Throwing a promise directly will be deprecated.

Todo

  • [ ] This can currently infinite loop if you use an uncached promise outside of a Suspense boundary. It's because this is an edge case where there's no fallback we can display, so it never switches to concurrent rendering. Might need to special case this.

Forked On 11 Aug 2022 at 09:40:21

Sophiebits

This public API is intentional? Promise.allSettled calls it `reason` not `value` for rejections. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled
On 11 Aug 2022 at 09:40:21

Sophiebits

experimental_use(promise)

Based on #25074

Adds experimental support to Fiber for unwrapping the value of a promise inside a component. It is not yet implemented for Server Components, but that is planned.

If promise has already resolved, the value can be unwrapped "immediately" without showing a fallback. The trick we use to implement this is to yield to the main thread (literally suspending the work loop), wait for the microtask queue to drain, then check if the promise resolved in the meantime. If so, we can resume the last attempted fiber without unwinding the stack. This functionality was implemented in previous commits.

Another feature is that the promises do not need to be cached between attempts. Because we assume idempotent execution of components, React will track the promises that were used during the previous attempt and reuse the result. You shouldn't rely on this property, but during initial render it mostly just works. Updates are trickier, though, because if you used an uncached promise, we have no way of knowing whether the underlying data has changed, so we have to unwrap the promise every time. It will still work, but it's inefficient and can lead to unnecessary fallbacks if it happens during a discrete update.

When we implement this for Server Components, this will be less of an issue because there are no updates in that environment. However, it's still better for performance to cache data requests, so the same principles largely apply.

The intention is that this will eventually be the only supported way to suspend on arbitrary promises. Throwing a promise directly will be deprecated.

Todo

  • [ ] This can currently infinite loop if you use an uncached promise outside of a Suspense boundary. It's because this is an edge case where there's no fallback we can display, so it never switches to concurrent rendering. Might need to special case this.

Merged On 11 Aug 2022 at 09:42:57

Sophiebits

Commented On 11 Aug 2022 at 09:42:57

Sophiebits

experimental_use(promise)

Based on #25074

Adds experimental support to Fiber for unwrapping the value of a promise inside a component. It is not yet implemented for Server Components, but that is planned.

If promise has already resolved, the value can be unwrapped "immediately" without showing a fallback. The trick we use to implement this is to yield to the main thread (literally suspending the work loop), wait for the microtask queue to drain, then check if the promise resolved in the meantime. If so, we can resume the last attempted fiber without unwinding the stack. This functionality was implemented in previous commits.

Another feature is that the promises do not need to be cached between attempts. Because we assume idempotent execution of components, React will track the promises that were used during the previous attempt and reuse the result. You shouldn't rely on this property, but during initial render it mostly just works. Updates are trickier, though, because if you used an uncached promise, we have no way of knowing whether the underlying data has changed, so we have to unwrap the promise every time. It will still work, but it's inefficient and can lead to unnecessary fallbacks if it happens during a discrete update.

When we implement this for Server Components, this will be less of an issue because there are no updates in that environment. However, it's still better for performance to cache data requests, so the same principles largely apply.

The intention is that this will eventually be the only supported way to suspend on arbitrary promises. Throwing a promise directly will be deprecated.

Todo

  • [ ] This can currently infinite loop if you use an uncached promise outside of a Suspense boundary. It's because this is an edge case where there's no fallback we can display, so it never switches to concurrent rendering. Might need to special case this.

Merged On 11 Aug 2022 at 09:42:57

Sophiebits

Commented On 11 Aug 2022 at 09:42:57
Issue Comment

Sophiebits

Better diffs for indent changes.

Currently, one of the hardest diffs to review, is when a bunch of code gets indented positively or negatively. It's hard to tell if the user actually made a change somewhere in the indent code because it all mostly looks the same.

Here is prime example: https://gist.github.com/blainekasten/cfd44975df7c294c54e6/revisions

Hardly any code was changed, just de-indented.

It would help if we could see the actual code that changed, and then indent changes were hidden and noted. Something that looked more like this:

- removedThisFunction(function() {
+  de-indented containing content 2 spaces
- }); 

Forked On 08 Aug 2022 at 08:27:19

Sophiebits

For what it's worth, Reviewable handles @timotheecour's example well:

screenshot of diff in Reviewable showing the entire re-indented block, where the one re-indented line can also be identified by color highlighting

Commented On 08 Aug 2022 at 08:27:19
Issue Comment

Sophiebits

Reword "Invalid ARIA Prop Warning" advice
Forked On 05 Aug 2022 at 06:33:53

Sophiebits

Thanks!

Commented On 05 Aug 2022 at 06:33:53

Sophiebits

Reword "Invalid ARIA Prop Warning" advice (#4844)

Pushed On 05 Aug 2022 at 06:33:48

Sophiebits

Reword "Invalid ARIA Prop Warning" advice

Created On 05 Aug 2022 at 06:33:44
Issue Comment

Sophiebits

Bug: Ctrl-T on Mac should transpose characters

In a native Mac text field, pressing Ctrl-T will transpose the adjacent characters and move one character rightwards. i.e. given

a b c
 ^ cursor 

pressing Ctrl-T will give

b a c
   ^ cursor 

This shortcut doesn't work in Lexical. Reproed on lexical.dev and in Workplace UFI.

Forked On 04 Aug 2022 at 08:32:17

Sophiebits

Amazing!

Commented On 04 Aug 2022 at 08:32:17
Issue Comment

Sophiebits

Bug: Ctrl-T on Mac should transpose characters

In a native Mac text field, pressing Ctrl-T will transpose the adjacent characters and move one character rightwards. i.e. given

a b c
 ^ cursor 

pressing Ctrl-T will give

b a c
   ^ cursor 

This shortcut doesn't work in Lexical. Reproed on lexical.dev and in Workplace UFI.

Forked On 04 Aug 2022 at 07:44:06

Sophiebits

Nice. I noticed that Ctrl-K (also an emacs keybinding) seems to behave incorrectly in Lexical as well. It should delete to (but not including) the nearest \n (or end of string), or delete one \n if you're right before one. In Lexical it seems to be also deleting the newline and some of the characters from the next line, depending on your cursor position when pressing it.

Commented On 04 Aug 2022 at 07:44:06
Create Branch
Sophiebits In reactjs/reactjs.org Create Branchsophiebits-patch-4

Sophiebits

The React documentation website

On 27 Jul 2022 at 11:29:11

Sophiebits

Reword "Invalid ARIA Prop Warning" advice

Created On 27 Jul 2022 at 11:29:10
Issue Comment

Sophiebits

Support implicit <head> in hydration

When the browser parses html it will create a element even if the tag is not present. If you render at the root (either the document itself or the html element) the hydration will fail becasue this implicitly created head is not matched against the react component tree. Additionally the head will be removed from the document as an extraneous node which means any third party scripts or other tags that were inserted there by browser extensions or other means will be deleted which can break many tools.

This change adds the ability to mark certain instances as implicit and so after attempting to hydrate them they will be skipped over rather than dropped.

Forked On 21 Jul 2022 at 07:37:43

Sophiebits

Given the async nature I guess the warning could be for a <body> without a <head> then. Though I thought that typically the whole shell would come in at the same time including some the body content. Is there a point to rendering the opening <html> tag without any other content?

Commented On 21 Jul 2022 at 07:37:43
Issue Comment

Sophiebits

Support implicit <head> in hydration

When the browser parses html it will create a element even if the tag is not present. If you render at the root (either the document itself or the html element) the hydration will fail becasue this implicitly created head is not matched against the react component tree. Additionally the head will be removed from the document as an extraneous node which means any third party scripts or other tags that were inserted there by browser extensions or other means will be deleted which can break many tools.

This change adds the ability to mark certain instances as implicit and so after attempting to hydrate them they will be skipped over rather than dropped.

Forked On 21 Jul 2022 at 07:00:14

Sophiebits

Would it be better to warn when rendering <html> without a <head> child? eg for <table>, we require a <tbody> component to be explicitly rendered, rather than attempting to recover automatically. That way we don't need production code to handle it.

Commented On 21 Jul 2022 at 07:00:14

Sophiebits

[Beta] Adjusting Effect Dependencies

Preview

TODO

  • [x] Writing
  • [ ] Team review
  • [ ] Edit/simplify pass
  • [ ] Recap
  • [ ] Challenges

Forked On 21 Jul 2022 at 03:14:13

Sophiebits

I appreciate these well-placed parentheticals
On 21 Jul 2022 at 03:14:13

Sophiebits

[Beta] Adjusting Effect Dependencies

Preview

TODO

  • [x] Writing
  • [ ] Team review
  • [ ] Edit/simplify pass
  • [ ] Recap
  • [ ] Challenges

Forked On 21 Jul 2022 at 03:05:54

Sophiebits

```suggestion You're using `notificationCount` inside your Effect, so you must add it to the dependency list. However, if you do that, your Effect will re-run whenever the `notificationCount` changes. This doesn't make sense: a change to the number of notifications doesn't mean that the user visited the chat again. ```
On 21 Jul 2022 at 03:05:54

Sophiebits

[Beta] Adjusting Effect Dependencies

Preview

TODO

  • [x] Writing
  • [ ] Team review
  • [ ] Edit/simplify pass
  • [ ] Recap
  • [ ] Challenges

Forked On 21 Jul 2022 at 03:17:14

Sophiebits

I feel like it is a tiny bit confusing to have the green checkmark in the same code sample as the red Avoid. almost feels like it is contradicting it. ("yes there was an error above, but this makes up for it.") wdyt of just "// All dependencies declared" for these?
On 21 Jul 2022 at 03:17:14

Sophiebits

[Beta] Adjusting Effect Dependencies

Preview

TODO

  • [x] Writing
  • [ ] Team review
  • [ ] Edit/simplify pass
  • [ ] Recap
  • [ ] Challenges

Forked On 21 Jul 2022 at 03:11:29

Sophiebits

this example rewrite is fine but I feel like it's also legit to have stable identity as part of the contract for the component, especially if the options type is from a third-party (here, websocket) library – saying "connectionOptions prop; each time it changes the connection will be reestablished; please useMemo" – wdyt?
On 21 Jul 2022 at 03:11:29

Sophiebits

[Beta] Adjusting Effect Dependencies

Preview

TODO

  • [x] Writing
  • [ ] Team review
  • [ ] Edit/simplify pass
  • [ ] Recap
  • [ ] Challenges

Forked On 21 Jul 2022 at 03:06:42

Sophiebits

although you can kind of infer it, I think this needs some explicit commentary on why roomId is an argument instead of captured
On 21 Jul 2022 at 03:06:42