Convert SearchTracePage/SearchForm to functional component

[JeevaRamanathan]

Which problem is this PR solving?

• [Feature]: Refactor class components to functional components #2610

Description of the changes

• convert packages/jaeger-ui/src/components/SearchTracePage/SearchForm.jsx from class to functional and improved test cases.

How was this change tested?

• Ensured there is no break in the functionality in UI
• Ran the test suite using npm run test to ensure all test cases pass.

Checklist

• I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
• I have signed all commits
• I have added unit tests for the new functionality
• I have run lint and test steps successfully
  • for jaeger: make lint test
  • for jaeger-ui: npm run lint and npm run test

[graphite-app]

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[codecov]

Codecov Report

❌ Patch coverage is 91.66667% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.88%. Comparing base (49963bf) to head (a2c9b83).

Files with missing lines	Patch %	Lines
...r-ui/src/components/SearchTracePage/SearchForm.jsx	91.66%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3078      +/-   ##
==========================================
- Coverage   97.92%   97.88%   -0.05%     
==========================================
  Files         260      260              
  Lines        8162     8162              
  Branches     2151     2124      -27     
==========================================
- Hits         7993     7989       -4     
- Misses        169      173       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[graphite-app]

There's a potential race condition in the service selection logic. Currently, when a service is selected, two separate setFormData calls occur in sequence:

1. First call updates the service field
2. Second call resets the operation to DEFAULT_OPERATION

Since React state updates are batched and asynchronous, the second update might not see the changes from the first update, potentially causing inconsistent state.

Consider combining both updates into a single setFormData call:

setFormData(prevState => ({
  ...prevState,
  ...fieldData,
  operation: fieldData.service ? DEFAULT_OPERATION : prevState.operation
}));

This ensures both the service update and operation reset happen atomically in a single state update.

Suggested change

	changeServiceHandler(fieldData.service);
	setFormData(prevState => ({
	...prevState,
	operation: DEFAULT_OPERATION,
	}));
	setFormData(prevState => ({
	...prevState,
	...fieldData,
	operation: fieldData.service ? DEFAULT_OPERATION : prevState.operation
	}));

Spotted by Diamond



Is this helpful? React 👍 or 👎 to let us know.

[yurishkuro]

how is this equivalent to checking that the handler was called?

[JeevaRamanathan]

Yeah I agree, after converting to a functional component, the handleChangeMock is not working properly with the current implementation. I'll check again. Your guidance on the section would be appreciated.

[JeevaRamanathan]

Hi @yurishkuro, I have updated this retaining the same check. Can you please check and let know if this looks good or any further changes is required

[yurishkuro]

it is unusual to change unit tests when performing migration to functional component. It may indicate that you're breaking the functionality.

[JeevaRamanathan]

Hi @yurishkuro,

jaeger-ui/packages/jaeger-ui/src/components/SearchTracePage/SearchForm.test.js

Lines 432 to 435 in 30a402d

	class TestSearchForm extends SearchForm {
	componentDidMount() {
	this.handleChange({ service: 'svcC' });
	}

jaeger-ui/packages/jaeger-ui/src/components/SearchTracePage/SearchForm.test.js

Lines 520 to 534 in 30a402d

	it('prevents default form submission behavior', () => {
	class TestSearchForm extends SearchForm {
	componentDidMount() {
	const mockEvent = { preventDefault: jest.fn() };
	this.handleSubmit(mockEvent);
	expect(mockEvent.preventDefault).toHaveBeenCalled();
	expect(this.props.submitFormHandler).toHaveBeenCalledWith(this.state.formData);
	}
	}
	render(<TestSearchForm {...defaultProps} />);
	});
	});

Yeah, but in few cases like above test changes were necessary because those tests were directly extending the SearchForm class and accessing internal methods; when converting to a functional component, these class-based patterns don't work anymore since there's no class to extend or this context to access and the tests were failing.

[yurishkuro]

Ensured there is no break in the functionality in UI

how?

[JeevaRamanathan]

how?

I manually tested the SearchForm with various inputs, verified correct functionality, results, and layout visually, and also ran the test suite. Please let me know if anything was missed

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. You may re-open it if you need more time.

[yurishkuro]

why is this needed? normally functional components are just pure functions