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

Feature/239 evident see offers wo user parameters #286

Merged

Conversation

tomaspalma
Copy link
Member

@tomaspalma tomaspalma commented Dec 6, 2022

Closes #239. The solution implemented was displaying a "search" button when there were no user specified filters nor any value in the search bar. Then, when the user chooses a filter or writes something in the search bar, it changes the button text to "search"

image

image

image

@Naapperas
Copy link
Member

@tomaspalma You need to fix the failing test, since the current behavior will change.

@tomaspalma
Copy link
Member Author

@tomaspalma You need to fix the failing test, since the current behavior will change.

It is now fixed.

Should we also add tests to see if the searchHasUserInput variable is set to the correct value when the search bar isn't empty and when any filters are activated? because this test only tests if the behaviour is correct when a certain value of searchHasUserInput is set but it doesn't validate that the value of the searchHasUserInput is correctly set under the supposed circumstances.

Also, I have a question in the file I worked on. Why is that the component name in the SubmitSearchButton.js file is called "ShowAdvancedOptionsButton"?

@codecov-commenter
Copy link

codecov-commenter commented Dec 19, 2022

Codecov Report

Base: 88.97% // Head: 88.99% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (76c12f3) compared to base (8fa5a07).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #286      +/-   ##
===========================================
+ Coverage    88.97%   88.99%   +0.01%     
===========================================
  Files          175      175              
  Lines         3302     3307       +5     
  Branches       829      834       +5     
===========================================
+ Hits          2938     2943       +5     
  Misses         364      364              
Impacted Files Coverage Δ
src/components/HomePage/SearchArea/SearchArea.js 100.00% <100.00%> (ø)
...mponents/HomePage/SearchArea/SubmitSearchButton.js 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@Naapperas
Copy link
Member

Naapperas commented Dec 22, 2022

@tomaspalma the only thing missing in this is to write the test that we talked about in a meeting, or is there something else?

Other than that, you'll need to rebase this with develop

@Naapperas
Copy link
Member

@tomaspalma The failing tests may need more props that are mandatory.

Copy link
Member

@Naapperas Naapperas left a comment

Choose a reason for hiding this comment

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

LGTM, the only thing left is to fix the tests but I have explained what should be done for that so it should not be too complicated.

@tomaspalma
Copy link
Member Author

tomaspalma commented Jan 19, 2023

@tomaspalma The failing tests may need more props that are mandatory.

I was unsure if there was something really missing on the props or whether it was some other issue because locally running npm test the result was an all-green suite. It was only failing with the ci tests.

But now seeing what you said and looking at the other tests that render searchArea in searchArea.spec.js, the component is being rendered in those tests with some props I'm not passing in the tests I created, including the one that is saying not to be defined in the error report of the ci tests, the other props probably aren't showing as undefined because setShowJobDurationSlider appears first in the searchArea component code, so it may be that.

Update: The tests we failling locally because I had an outdated version of the program code, because I had forgotten to rebase with develop.

@tomaspalma tomaspalma force-pushed the feature/239-evident-see-offers-wo-user-parameters branch from 678d8e2 to 2907e99 Compare January 20, 2023 21:37
@tomaspalma
Copy link
Member Author

It is not ready yet, there's still an issue that came up after updating the changes on develop and the searchValue comes initially as undefined instead of empty string, so the show all button is not currently showing at start.

@Naapperas
Copy link
Member

Naapperas commented Jan 21, 2023

It is not ready yet, there's still an issue that came up after updating the changes on develop and the searchValue comes initially as undefined instead of empty string, so the show all button is not currently showing at start.

Maybe you can change the initial value of the redux state for the offerSearch, it is defined in the offer's reducer if I'm not mistaken.

Another option is to check if it is undefined.

Copy link
Member

@Naapperas Naapperas left a comment

Choose a reason for hiding this comment

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

I believe I have done something similar to what I have described in the review comments but perhaps I'm mistaken.

Edit: FOUND IT!! It was in this PR: #284 and on this file src/components/HomePage/SearchArea/AdvancedSearch/AdvancedSearchDesktop.spec.js.

@tomaspalma
Copy link
Member Author

tomaspalma commented Jan 22, 2023

I think it's pratically done now, already fixed show all not showing at start and also added the search area wrapper to improve readiblity in the tests. Contrarily to the example you gave me, I had to specify the prop types because the linter was giving me warnings about not specifying the types for them.

@Naapperas
Copy link
Member

I think it's pratically done now, already fixed show all not showing at start and also added the search area wrapper to improve readiblity in the tests. Contrarily to the example you gave me, I had to specify the prop types because the linter was giving me warnings about not specifying the types for them.

Just as a future reference you can instruct the linter to ignore those warnings, which is useful for cases like this one.

@tomaspalma tomaspalma force-pushed the feature/239-evident-see-offers-wo-user-parameters branch from 76c12f3 to fd39302 Compare January 29, 2023 12:44
Copy link
Member

@Naapperas Naapperas left a comment

Choose a reason for hiding this comment

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

LGTM 🚀

@tomaspalma tomaspalma force-pushed the feature/239-evident-see-offers-wo-user-parameters branch from fd39302 to 6f0c2cc Compare February 1, 2023 00:16
@tomaspalma tomaspalma merged commit 5905379 into develop Feb 1, 2023
@tomaspalma tomaspalma deleted the feature/239-evident-see-offers-wo-user-parameters branch February 1, 2023 10:13
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.

Make more evident how to see offers without search parameters
4 participants