Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix(site): show available logs consistently on template creation page#19832

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
aslilac merged 10 commits intomainfromlilac/fix-bad-logging-conditions
Sep 16, 2025

Conversation

aslilac
Copy link
Member

@aslilacaslilac commentedSep 15, 2025
edited
Loading

Closes#19704

The condition on this page was subtly wrong in a very annoying way. :^)

Copy link
Member

@ParkreinerParkreiner left a comment

Choose a reason for hiding this comment

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

Conditional logic looks right to me, but the effects have me concerned

@ParkreinerParkreiner changed the titlefix: show logs consistently when there are logs to be shown on the template creation pagefix(site): show available logs consistently on template creation pageSep 16, 2025
@aslilac
Copy link
MemberAuthor

aslilac commentedSep 16, 2025
edited
Loading

after staring at this for a while, I realized that the effects were weird because they're just in the wrong place. 😅 aaand that every place that uses this component re-implements the autoscrolling behavior itself. it should really just scroll itself, and that makes a bunch of complexity vanish.

Copy link
Member

@ParkreinerParkreiner left a comment

Choose a reason for hiding this comment

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

I think this makes sense for a stopgap. I'm just not a fan of the randomlogs expression used to suppress the Biome warnings


constref=useRef<HTMLDivElement>(null);
useLayoutEffect(()=>{
logs;
Copy link
Member

@ParkreinerParkreinerSep 16, 2025
edited
Loading

Choose a reason for hiding this comment

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

This feels janky to me. I think I'd rather have the Biome warning suppression, because it feels more "honest" about this not being a properly-defined synchronization effect

I think there's a "deeper" fix we can reach for to remove the effect entirely. I just don't know if it makes to do it now. ForBuildLogsDrawer at least, we could:

  1. Update the logs component to accept a forwarded ref, and get rid of the old ref + layout logic
  2. Define the ref inBuildLogsDrawer
  3. UpdateuseWatchVersionLogs to accept anonMessage callback that fires each time a new message comes in
  4. HaveBuildLogsDrawer pass the ref down to the logs component, and also pass anonMessage callback to the hook that handles the scrolling behavior

Copy link
Member

@ParkreinerParkreinerSep 16, 2025
edited
Loading

Choose a reason for hiding this comment

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

The big problem right now is that ideally these scrolls would be handled in an event handler, but the state isn't defined in a way that gives you a state setter function that's easy to wrap

Plus, there's five components currently using this

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

one day we'll get signals...

Copy link
Member

@ParkreinerParkreinerSep 16, 2025
edited
Loading

Choose a reason for hiding this comment

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

I mean, the problem with the React team is that they legitimately think that they don't need signals, and that the compiler is going to solve all of React's problems (which it probably won't). They've turned down a few signal proposals already

Copy link
MemberAuthor

@aslilacaslilacSep 16, 2025
edited
Loading

Choose a reason for hiding this comment

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

it'll take a while, but I'm pretty sure the web platform will get signals soon, and then the react team will be forced to reckon with them.

also preact even jumped the gun and added signals. angular has signals now. the tide is turning!

@aslilacaslilac merged commitf5fac29 intomainSep 16, 2025
32 checks passed
@aslilacaslilac deleted the lilac/fix-bad-logging-conditions branchSeptember 16, 2025 20:33
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsSep 16, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@ParkreinerParkreinerParkreiner approved these changes

@jaaydenhjaaydenhAwaiting requested review from jaaydenh

Assignees

@aslilacaslilac

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

bug: Web UI does not surface errors in template creation
2 participants
@aslilac@Parkreiner

[8]ページ先頭

©2009-2025 Movatter.jp