Channel cards to unstable#5696
Conversation
Unstable to channel cards branch
KDS has recently started providing visuallyhidden so is not needed.
and related re-organization of files and tests. Also adds more tests to some components.
fb06598 to
bec64b0
Compare
e5ef964 to
6588fd0
Compare
shape of loaded cards.
contentcuration/contentcuration/frontend/channelList/composables/useChannelList.js
Outdated
Show resolved
Hide resolved
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioChannelCard/index.vue
Outdated
Show resolved
Hide resolved
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioMyChannels/index.vue
Outdated
Show resolved
Hide resolved
|
Resolved. |
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioChannelsPage/index.vue
Show resolved
Hide resolved
contentcuration/contentcuration/frontend/channelList/views/Channel/CatalogList.vue
Outdated
Show resolved
Hide resolved
contentcuration/contentcuration/frontend/channelList/views/Channel/CatalogList.vue
Outdated
Show resolved
Hide resolved
akolson
left a comment
There was a problem hiding this comment.
I think code is clear and understandable. Thanks Misha for this refactor!
to prevent unnecessary memory usage and to improve architecture. Relatedly remove props for configuring footer in favor of the footer slot to make communication between the modals and footer buttons straightforward.
in channel token modal and remove unnecessary token tracking handlers from components (StudioCopyToken handles tracking)
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioMyChannels/index.vue
Outdated
Show resolved
Hide resolved
rtibblesbot
left a comment
There was a problem hiding this comment.
Well-structured PR that replaces Vuetify-based channel cards with KDS KCard across four pages, with a clean architectural decomposition from monolithic ChannelList+ChannelItem into focused per-page components.
CI passing. Screenshots verified for My Channels, Starred, View-only, and Content Library — all look visually consistent and complete.
Suggestions:
- Missing
notranslateclass anddir="auto"on channel description inStudioChannelCard(see inline comment) - Missing error handling in
useChannelListcomposable — rejected dispatch leaves loading state stuck (see inline comment)
Praise:
- Excellent decomposition into
StudioMyChannels,StudioStarredChannels,StudioViewOnlyChannelswith sharedStudioChannelCardandStudioChannelsPagelayout - Thorough test suites using
@testing-library/vuecovering dropdown menus, modal flows, navigation, and conditional rendering - Good extraction of
useChannelListcomposable for shared channel-loading logic
Note: As mentioned in the PR description, the temporary KDS fork in package.json needs to be reverted before merge.
@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly
How was this generated?
Reviewed the pull request diff checking for:
- Correctness: bugs, edge cases, undocumented behavior, resource leaks, hardcoded values
- Design: unnecessary complexity, naming, readability, comment accuracy, redundant state
- Architecture: duplicated concerns, minimal interfaces, composition over inheritance
- Testing: behavior-based assertions, mocks only at hard boundaries, accurate coverage
- Completeness: missing dependencies, unupdated usages, i18n, accessibility, security
- Principles: DRY (same reason to change), SRP, Rule of Three (no premature abstraction)
- Checked CI status and linked issue acceptance criteria
- For UI changes: inspected screenshots for layout, visual completeness, and consistency
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioChannelCard/index.vue
Show resolved
Hide resolved
contentcuration/contentcuration/frontend/channelList/composables/useChannelList.js
Outdated
Show resolved
Hide resolved
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioChannelsPage/index.vue
Show resolved
Hide resolved
...ation/frontend/channelList/views/Channel/StudioMyChannels/__tests__/StudioMyChannels.spec.js
Show resolved
Hide resolved
rtibblesbot
left a comment
There was a problem hiding this comment.
Clean follow-up addressing prior feedback. CI pending (linting, frontend build, frontend tests). Screenshots verified — all four pages look visually complete and consistent.
1 prior finding(s) resolved.
Suggestions:
- Empty-state "No channels found" may not display when a user has zero channels (see inline comment on StudioChannelsPage)
Praise:
- StudioStarredChannels tests nicely cover both editable and view-only channel behaviors within the same page, testing the conditional dropdown logic thoroughly
@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly
How was this generated?
Compared the current PR state against findings from a prior review:
- Retrieved prior bot reviews deterministically via the GitHub API
- Classified each prior finding as RESOLVED, UNADDRESSED, ACKNOWLEDGED, or CONTESTED
- Only raised NEW findings for newly introduced code
- Reviewed the pull request diff checking for correctness, design, architecture, testing, completeness, and adherence to DRY/SRP principles
- Checked CI status and linked issue acceptance criteria
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioChannelsPage/index.vue
Show resolved
Hide resolved
...tend/channelList/views/Channel/StudioStarredChannels/__tests__/StudioStarredChannels.spec.js
Show resolved
Hide resolved
rtibblesbot
left a comment
There was a problem hiding this comment.
Clean delta — prior feedback addressed.
CI: linting and frontend tests passing; build frontend assets still pending. Screenshots previously verified.
2 prior finding(s) resolved.
Suggestions:
- None
Reminders:
- KDS fork in
package.jsonstill needs reverting before merge (as noted in PR description)
@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly
How was this generated?
Compared the current PR state against findings from a prior review:
- Retrieved prior bot reviews deterministically via the GitHub API
- Classified each prior finding as RESOLVED, UNADDRESSED, ACKNOWLEDGED, or CONTESTED
- Only raised NEW findings for newly introduced code
- Reviewed the pull request diff checking for correctness, design, architecture, testing, completeness, and adherence to DRY/SRP principles
- Checked CI status and linked issue acceptance criteria
contentcuration/contentcuration/frontend/channelList/views/Channel/StudioMyChannels/index.vue
Show resolved
Hide resolved
| await userEvent.click(within(menu).getByText('Copy channel token')); | ||
| await waitFor(() => { | ||
| expect( | ||
| screen.getByText('Paste this token into Kolibri to import this channel'), |
There was a problem hiding this comment.
this isn't blocking and is just a question as we've been discussing tests across the ecosystem and VTL (and this makes me think about one other PR that I reviewed a few weeks ago). It seems like many of these tests introduced in this PR are getByText which seems to be a new pattern. it seems mostly to just exist unstable around new tests. Of course, adding tests has been a helpful part of the community contributor work. At the same time, think that for some of these new tests, it's a level of granularity that isn't necessarily useful.
at this point in the work, I don't think rewriting the tests is necessary. But I do think that this pattern will continue to be used as people see it for reference, especially community contributors. Would there be anything helpful we can do around decisions about VTL and data-testid that would be helpful to update in documentation? Also -- it's possible I missed something about this pattern, I did look through slack and only saw the discussion regarding data-testid and pointing people to the VTL docs.
There was a problem hiding this comment.
@marcellamaki I think there was a confusion that I might have contributed to, apologies. data-testid is indeed useful, but that guidance is specific to contexts when it's not possible to use other queries, or when other approaches result in complicated test setup (e.g. many stubs).
Before we even get to data-testid there are many other options. I think it'd be best to just use this guidance? https://testing-library.com/docs/queries/about/#priority
There was a problem hiding this comment.
And then there's another discussion we had around data-test vs data-testid ~ but again that would too apply only when we have no other option than data test ID. Happy to chat about this more.
There was a problem hiding this comment.
Thanks, Misha. I can definitely understand that data-testid isn't suitable for all options, but this is helpful -- I do think I was a bit confused, but it's clearer now :)
marcellamaki
left a comment
There was a problem hiding this comment.
@MisRob thanks for the work on this and @bjester and @akolson for the thoughtful feedback. I went through and did manual QA and did some code review as well, and it looks like everything has been addressed. I did add one non-blocking comments about tests, but it's more of a note for a future conversation not something to resolve right now.
|
Pushed one last commit to resolve #5696 (comment) & will merge briefly so we can start QA! Thanks all :) |
Summary
Replaces Vuetify-based implementation by
KCardon My Channels, Starred Channels, View-only Channels, and Content Library pages. On this opportunity introduces a new architecture of the related pages and resolves problems with understanding & maintaining monolithic and condition-heavyChannelList+ChannelItem.References
Closes #5227
Closes #5524
Closes #5525
Closes #5526
Reviewer guidance
Code review:
Local preview:
pnpm installfirstNotes
Before merging, [TODO REVERT] Temporarily install KDS fork commit needs to be reverted and a newly released KDS version with learningequality/kolibri-design-system#1203 installed.