React: Add More Cases to Server Rendering Fixture

[sebmarkbage]

Server rendering has a lot of quirks that are easy to break. We have a fixture set up for it in /fixtures/ssr.

This could be expanded to have more stuff in it. A few things we should have in the fixture and test for:

• <input />, <select />, <option /> and <textarea /> controlled and uncontrolled. All types of inputs, including dates, numbers etc.
• Where children is a single string/number, children array with multiple string/numbers, children with interleaved nodes and string/numbers.
• Event handlers on hydrated nodes that does something useful when clicked. Reused event handlers on multiple different nodes etc.
• onLoad event handlers.
• Special properties that don't map directly to attribute names like className.
• <div hidden>...</div> subtrees. (Subtrees with the "hidden" attribute set on it. Tests deprioritization.)

We probably need some on-screen options to turn on/off these things in the test suite to test under these conditions:

• Server and Client differences. Turn on a flag that makes the server and client differ in minor ways.
• Async hydration. Use Fiber's async features to hydrate the tree.
• Defer hydration for some time. This is useful to test slow loading conditions where the user may have changed state of form controls before hydration. When combined with async, it can make the async rendering artificially slow. It should reveal issues such as a patching or event handlers being attached too early (before commit phase).

It's ok to start small. You don't have to do it all at once.

[aickin]

Sorry for a noob question, but is there something written down about how the fixtures differ from the unit test suite? Am I right in my impression that fixtures are not run in CI and are more meant to be looked at by humans?

[aweary]

Am I right in my impression that fixtures are not run in CI and are more meant to be looked at by humans?

@aickin this is correct, assuming the SSR fixtures are setup like the DOM ones.

[gaearon]

Yep. They're for things that are hard to catch in automated way (e.g. things that don't replicate in jsdom). We could've added Selenium for this but having manual fixtures to bisect against so far seems like less hassle than dealing with flaky integration tests.

[RUPOJS]

Is this already done ? I want to take this up. Please let me know if I can take this. Also, it would be great if you can point me to the right direction for starting this one. TIA.

[gaearon]

I don't think this is taken—please feel free to work on it.

The first post describes where the code lives and what should be done. If you have more specific questions as you work on this, please post in this thread, and we'll try to answer!

[lanskey]

Hey @RUPOJS, Did you made any progress on this?

[sw-yx]

interested. will take a look at this this weekend.

[clemmy]

@sw-yx Awesome! Can you also look into adding some fixtures for fragments as well? You can enable them by changing this flag to true and see the tests for its usage here.

[sw-yx]

ok. the reason im not immediately jumping at this is i dont actually have much experience with SSR (or fragments for that matter). nextjs has spoiled me lol. so this is a nice way to force myself to learn it i guess.

[clemmy]

@sw-yx Thanks for taking on this task. Please feel free to ask if you need anything.

[sw-yx]

ok, I will take this on. Sebastian specified a lot of things here, I will implement incrementally and hopefully do this with some supervision in case I go too off track.

we surprisingly dont have a section in the reactjs docs dedicated to SSR. in fact just searching "server side" doesnt provide useful results, you need to search "hydrate" in order to find it. that's probably a good issue to raise over at reactjs docs.

[sw-yx]

I am proceeding extremely cautiously here. I'm thinking eventually what this will look like is a very long page with all the bullet points @sebmarkbage laid out in the first half of his spec. I was originally thinking to split it up into tabs but then that might confound our SSR testing.

So what I want to confirm here is if I have a good understanding of what you guys envision controlled/uncontrolled fixtures are. See here:

[adrienharnay]

Hey @sw-yx, do you need any help on this? I could do some bullet points if you want

[sw-yx]

@Zephir77167 yes I would like help. basically i was waiting for someone to help confirm that i am on the right track. #11451 was supposed to address @sebmarkbage's first bullet point:

    <input />, <select /> controlled and uncontrolled

if this is what we want, i can proceed to complete out the rest of the first bullet point:

    <input />, <select />, <option /> and <textarea /> controlled and uncontrolled. All types of inputs, including dates, numbers etc.

Since this fixture page will have a lot of examples, I'm also wondering if I should put these items into tabs so that they don't clutter the page. I think this may have some consequences with regards to SSR so I am avoiding it for now but it might be a good idea.

[adrienharnay]

I was thinking about a tab system with a query parameter to define the initial tab, however I don't think it is possible to access the URL from the server with the current setup. Maybe we should stack them on a single page, or make one page per bullet point?

Once @sebmarkbage will have validated this is going the right way, I will begin with the second bullet point!

[sw-yx]

Tagging @clemmy - do you think @Zephir77167 and I have the right understanding of how to flesh out this fixture?

main things we want to confirm:

1. Is what i laid out in my PR and gif useful for the fixture?
2. Sebastian specified a -lot- of things to have, should we do a tab system to avoid having a super long page, or would that be a bad idea because we are trying to do SSR?

thanks

[gaearon]

I'm going on vacation so can't review but I'll ask somebody to follow up.

[nhunzaker]

Took a pass in #11451. As for your questions:

1. I think this is great. As a comparison, we have a standard format for fixtures in the DOM test fixtures. (example here), but I don't think that should necessarily prescribe the approach you take.
2. Using state to manage the tabs would circumvent SSR. A tab system that used URLs with hard page refreshes seems ideal, or a select dropdown that switches the URL to load a new page. However I wouldn't worry about it for now.

Thanks for taking this on!

[sw-yx]

11451 is updated with the new proposed structure for all the elements. we could try to reach consensus on format and merge the big picture structure, and then split out the work into a bunch of smaller issues and PRs to make this work.

1. i stole the DOM test format wholesale, i think we have some calls to make on whether to cut down extraneous tests as it gets a little messy but the format is excellent.
2. i am using good old a anchors to do a table of contents system. my ssr fixture now looks like a webpage circa 1999. i almost want to have a rotating React marquee gif.

[sw-yx]

pinging @nhunzaker when you have a sec to take a look again! thanks!

[sw-yx]

hey folks just bumping this - not sure if i should just leave it be or something. guidance appreciated! i know this isnt the highest priorrity.

[gaearon]

Sorry, we've been pretty busy wrapping things up before the holidays. I'll try to do a pass through PRs in the next few days.

[sw-yx]

no worries at all, i know you've had a ton of stuff on your plate. i briefly chatted with @nhunzaker on twitter about this and am happy to carry on working on this under his guidance.

[eragon512]

hey guys, I'd like to take up this issue if its available

[sw-yx]

it is, please take note of the concerns raised in https://github.com/facebook/react/pull/11451 though. good luck.

[eragon512]

hey @sw-yx , I've kickstarted the work for this issue in #15551
I have added fixtures for all the various <input /> types, <select /> as well as <textarea />, continuing the work done in #11451

Basic UI screenshot:

Could you please verify whether I am on the right track for progressing on this issue?

[sw-yx]

i'm not a maintainer. pinging @nhunzaker

[eragon512]

hey, @sw-yx @nhunzaker , is this issue still open for contributions?