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 98.09%. Comparing base (1e7053e) to head (4b51f34).

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   98.14%   98.09%   -0.05%     
==========================================
  Files         257      257              
  Lines        8065     8065              
  Branches     2031     2033       +2     
==========================================
- Hits         7915     7911       -4     
- Misses        150      154       +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?