Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(core): make PTE active by default #8778

Open
wants to merge 1 commit into
base: next
Choose a base branch
from
Open

Conversation

christianhg
Copy link
Member

Description

There's been some feedback internally and externally that it would be nice if the Portable Text Input was active by default. So I think we should try it.

Therefore, the default value of the PortableTextInput.initialActive prop has been flipped from false to true.

What to review

Does it work as expected? Is an input with initialActive={false} correctly made inactive on mount?

Testing

Some existing component tests have been adjusted to match the new behaviour.

Notes for release

The Portable Text Input is now active by default

There's been some feedback internally and externally that it would be nice if
the Portable Text Input was active by default. So I think we should try it.

Therefore, the default value of the `PortableTextInput.initialActive` prop has
been flipped from `false` to `true`.
@christianhg christianhg requested a review from a team as a code owner February 26, 2025 15:16
@christianhg christianhg requested review from binoy14 and removed request for a team February 26, 2025 15:16
Copy link

vercel bot commented Feb 26, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
page-building-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 26, 2025 3:21pm
performance-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 26, 2025 3:21pm
test-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 26, 2025 3:21pm
2 Skipped Deployments
Name Status Preview Comments Updated (UTC)
studio-workshop ⬜️ Ignored (Inspect) Feb 26, 2025 3:21pm
test-next-studio ⬜️ Ignored (Inspect) Feb 26, 2025 3:21pm

Copy link
Contributor

⚡️ Editor Performance Report

Updated Wed, 26 Feb 2025 15:28:06 GMT

Benchmark reference
latency of sanity@latest
experiment
latency of this branch
Δ (%)
latency difference
recipe (name) 43.5 efps (23ms) 40.0 efps (25ms) +2ms (+8.7%)
recipe (description) 45.5 efps (22ms) 45.5 efps (22ms) +0ms (-/-%)
recipe (instructions) 99.9+ efps (6ms) 99.9+ efps (6ms) +0ms (-/-%)

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark latency p75 p90 p99 blocking time test duration
recipe (name) 23ms 25ms 27ms 55ms 15ms 7.1s
recipe (description) 22ms 23ms 25ms 50ms 0ms 5.2s
recipe (instructions) 6ms 8ms 9ms 25ms 0ms 3.3s

🧪 Experiment result

The performance result of this branch

Benchmark latency p75 p90 p99 blocking time test duration
recipe (name) 25ms 27ms 31ms 49ms 0ms 7.9s
recipe (description) 22ms 25ms 27ms 43ms 18ms 5.2s
recipe (instructions) 6ms 7ms 9ms 21ms 0ms 3.2s

📚 Glossary

column definitions

  • benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
  • latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
  • p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
  • p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
  • p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
  • blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
  • test duration — how long the test run took to complete.

Copy link
Contributor

@binoy14 binoy14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense to me, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants