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

Integrate search resource selection #13008

Open
wants to merge 14 commits into
base: develop
Choose a base branch
from

Conversation

AlexVelezLl
Copy link
Member

@AlexVelezLl AlexVelezLl commented Jan 15, 2025

Summary

  • Integrate search filters panel to lesson resource selection
  • Add a new immersive header to the side panel modal component.
Compartir.pantalla.-.2025-01-15.17_44_57.mp4

References

Closes #12987

Reviewer guidance

  • Edit a lesson
  • Change browser route path from "/lesson" to "lessontemp".
  • Click on "Manage resources".
  • Click on the search button from the first page on the side panel, or from within any topic
  • Play and try any possible combination with different filters, browsing search results topics, browser back/forward buttons navigation, etc.

@github-actions github-actions bot added APP: Coach Re: Coach App (lessons, quizzes, groups, reports, etc.) DEV: frontend labels Jan 15, 2025
@AlexVelezLl AlexVelezLl force-pushed the integrate-search-resource-selection branch from c731c48 to f982e74 Compare January 16, 2025 15:04
@marcellamaki
Copy link
Member

@pcenov - this is not urgent, but depending on how time consuming your laptop reset process is, this could go to the top of your list for Friday or Monday. Thank you!

@pcenov
Copy link
Member

pcenov commented Jan 20, 2025

Hi @AlexVelezLl and @marcellamaki - I confirm that the search is integrated as specified above.

Here are a few general observations based on my testing which can probably be tracked as follow-up issues if not already tracked somewhere else:

  1. We probably need to indicate in a better way within the search panel that there are no channels to import from when there aren't any as currently this is what I see in that case:

2025-01-20_14-45-55

  1. As specified in Figma, when we open the search panel the Category filter should be expanded by default while currently it's not:

category

3 There are quite a few design differences if the current implementation is closely compared to Figma such as the back arrow and the label are not centered, the keywords label should be removed, the icons for the categories are not added etc. Since I am not sure if this is in scope for this PR I am just mentioning it here as a consideration:

differences

  1. When searching by selecting filters it's not immediately clear how the user should proceed the search (the user has to click the search icon next to the empty keywords field). In this case I was expecting to immediately see the filtered results after having applied a filter:
not.clear.how.to.proceed.mp4
  1. When testing the mobile view in Chrome's mobile devices emulator everything looks ok, but when I open the search panel in Chrome on my Samsung Note 10 phone I can only see the 'N resources selected' text and not the "Save & Finish" button as it's covered by the device's taskbar:

2025-01-20_15-44-38

Copy link
Member

@nucleogenesis nucleogenesis left a comment

Choose a reason for hiding this comment

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

Overall the changes are looking good. I left a handful of largely non-blocking comments. Happy to chat further about anything I noted.

I haven't finished going through every file yet, so I will be coming back to give a few parts another closer look

});
};

const useSearchObject = useBaseSearch({
Copy link
Member

Choose a reason for hiding this comment

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

I think this would be a little easier to read overall if you destructured everything out of useBaseSearch that you're using later on like const { displayingSearchResults, searchTerms, clearSearch, etc } = useBaseSearch(...) rather than assigning the return value to an object.

Copy link
Member

Choose a reason for hiding this comment

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

Looking again on another read, I get the sense that removing the context of where things like results and searchLoading are coming from might make it more confusing down where you use them to define values in searchFetch.

I'm definitely nitpicking pontificating at this point, but putting Object at the end of a variable name is a bit redundant. I get that the idea is to basically say "this is the thing that we got from useBaseSearch" so I think keeping it all as-is would be okay, but generally I try to avoid putting those kinds of things on variable names because anybody reading it can glean that by looking at the variable's definition.

Copy link
Member Author

Choose a reason for hiding this comment

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

In my experience it sometimes involves more cognitive load for me when we mix these variables that are scoped to an specific context with all other general variables, and more if we are going to use them just a single time, or if we are gonig just to return them from the main composable. But it's just a personal perception 😅, I have destructured the relevant variables from the useBaseSearch composable to see how it looks :), In my opinion, it doesn't hurt and we can keep them destructured, I'm fine with both options :).

Copy link
Member

Choose a reason for hiding this comment

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

For sure - I think in this context it makes sense to name the object and use it when accessing the values so it's clear where they're coming from.

loadingMore: useSearchObject.moreLoading,
fetchData: async () => {
// Make sure that the topic is loaded before searching
await waitForTopicLoad();
Copy link
Member

Choose a reason for hiding this comment

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

Calling the function waitForTopicLoad feels redundant w/ the await here when I read it as "await wait for topic load" as opposed to if it were called loadTopic.

Non-blocking as it's perfectly readable as-is and my comment is more a matter of preference

Copy link
Member Author

@AlexVelezLl AlexVelezLl Jan 21, 2025

Choose a reason for hiding this comment

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

Hmm I have seen these namings in other places and I have taken inspiration from there. e.g. in testing library, waitFor and waitForElementToBeRemoved methods, or this waitFor in this blog.

It makes sense to me that these methods are named like these, because what they do is to wait for something to happen. The await keyword is apart from the intention of the method. And for example, we can just have something like:

waitForTopicLoad().then(() => ...)

and would work exact the same. So in this context I think we can just ignore the await from the action we are expecting, and relate it to the intention of awaiting the promise the method is returning.

Let me know what you think :).

Copy link
Member

Choose a reason for hiding this comment

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

That makes sense to me! Thanks Alex.

},
computed: {
isTopic() {
return !this.content.isLeaf;
},
headingElement() {
return this.headingLevel ? `h${this.headingLevel}` : 'h3';
Copy link
Member

Choose a reason for hiding this comment

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

Non-blocking: given the default value of headingLevel the conditional could be removed here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!

@AlexVelezLl
Copy link
Member Author

Thanks @pcenov!

  1. I think this can be reported in a different issue :).
  2. Just implemed this!
  3. I have added the "Search in ..." as title on top of the search box when we open the filters from within a foder, and "Keywords" if we open it from the index (where we see the channels and bookmarks).

image

I think the icons are still not available cc: @marcellamaki, so probably should be reported in a different issue. And the border-bottom in the side panel modal header I think its something we have in develop but not in the figma specs. (honestly I am not sure neither about the reason of this difference but it has been accepted for a long time 😅 cc: @marcellamaki)

  1. @marcellamaki and @jtamiace will tell better about the expected behaviour of this. Right now the current implementation is that the user needs to click on the search button to open the search results.
  2. Im not being able to replicate this, I have tried it on my browser but it seems the line is breaking correctly. Could you provide more details how can I reproduce it?

image

@pcenov
Copy link
Member

pcenov commented Jan 22, 2025

Thank @AlexVelezLl,
Here are my comments for the issues we are discussing:

  1. I have reported a follow-up issue here Manage lesson resources > Search - No indication that there are no imported resources on the device #13021
  2. I confirm that this is fixed now.
    For points 3, 4 @marcellamaki pls let us know how to proceed. A note that in the Library page we are showing the results to the user immediately after applying the filter so that's my expectation for this search too. :)
  3. @AlexVelezLl in order to replicate the issue you need to check it in an actual mobile phone as the problem is caused by the device's taskbar. I have double checked that this happens consistently. :)

@AlexVelezLl AlexVelezLl force-pushed the integrate-search-resource-selection branch from 22dc161 to 26db2b8 Compare January 24, 2025 16:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
APP: Coach Re: Coach App (lessons, quizzes, groups, reports, etc.) DEV: frontend
Projects
None yet
4 participants