-
Notifications
You must be signed in to change notification settings - Fork 735
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
base: develop
Are you sure you want to change the base?
Integrate search resource selection #13008
Conversation
c731c48
to
f982e74
Compare
Build Artifacts
|
@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! |
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:
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:
not.clear.how.to.proceed.mp4
|
There was a problem hiding this 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({ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :).
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 :).
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
...ugins/coach/assets/src/views/lessons/LessonResourceSelectionPage/LessonContentCard/index.vue
Show resolved
Hide resolved
...ugins/coach/assets/src/views/lessons/LessonResourceSelectionPage/LessonContentCard/index.vue
Show resolved
Hide resolved
Thanks @pcenov!
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)
|
Thank @AlexVelezLl,
|
22dc161
to
26db2b8
Compare
Summary
Compartir.pantalla.-.2025-01-15.17_44_57.mp4
References
Closes #12987
Reviewer guidance