Skip to content

Channel cards to unstable#5696

Merged
MisRob merged 45 commits intolearningequality:unstablefrom
MisRob:channel-cards
Mar 6, 2026
Merged

Channel cards to unstable#5696
MisRob merged 45 commits intolearningequality:unstablefrom
MisRob:channel-cards

Conversation

@MisRob
Copy link
Member

@MisRob MisRob commented Feb 10, 2026

Summary

Replaces Vuetify-based implementation by KCard on 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-heavy ChannelList + ChannelItem.

Before After
my-channels-before my-channels-after
starred-channels-before starred-channels-after
view-channels-before view-channels-after
content-library-before content-library-after

References

Closes #5227
Closes #5524
Closes #5525
Closes #5526

Reviewer guidance

Code review:

  • 80% of work are community contributions that were reviewed by myself and some also by @rtibbles. Then I added a final layer of work: abstractions, cleanup, user experience as well as internal architecture optimizations, fixes for few regressions, ... => I think it'd most meaningful to review affected files as a whole.

Local preview:

  • Run pnpm install first
  • Preview My Channels, Starred Channels, and View-only Channels pages
  • Preview Content Library when logged in and logged out

Notes

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.

Copy link
Member

@bjester bjester left a comment

Choose a reason for hiding this comment

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

Some review comments

@MisRob
Copy link
Member Author

MisRob commented Feb 18, 2026

I've just noticed on screenshots that I lost the invitations box being a bit wider than cards. Will fix this ~ is good for visual priority.

Resolved.

Copy link
Member

@akolson akolson left a comment

Choose a reason for hiding this comment

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

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)
@MisRob MisRob requested a review from rtibblesbot March 4, 2026 13:15
Copy link

@rtibblesbot rtibblesbot left a comment

Choose a reason for hiding this comment

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

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 notranslate class and dir="auto" on channel description in StudioChannelCard (see inline comment)
  • Missing error handling in useChannelList composable — rejected dispatch leaves loading state stuck (see inline comment)

Praise:

  • Excellent decomposition into StudioMyChannels, StudioStarredChannels, StudioViewOnlyChannels with shared StudioChannelCard and StudioChannelsPage layout
  • Thorough test suites using @testing-library/vue covering dropdown menus, modal flows, navigation, and conditional rendering
  • Good extraction of useChannelList composable 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

@MisRob MisRob requested a review from rtibblesbot March 4, 2026 13:33
Copy link

@rtibblesbot rtibblesbot left a comment

Choose a reason for hiding this comment

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

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

@MisRob MisRob requested a review from rtibblesbot March 4, 2026 13:48
Copy link

@rtibblesbot rtibblesbot left a comment

Choose a reason for hiding this comment

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

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.json still 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

await userEvent.click(within(menu).getByText('Copy channel token'));
await waitFor(() => {
expect(
screen.getByText('Paste this token into Kolibri to import this channel'),
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

@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

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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 :)

Copy link
Member

@marcellamaki marcellamaki left a comment

Choose a reason for hiding this comment

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

@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.

@MisRob
Copy link
Member Author

MisRob commented Mar 6, 2026

Pushed one last commit to resolve #5696 (comment) & will merge briefly so we can start QA! Thanks all :)

@MisRob MisRob merged commit 4665226 into learningequality:unstable Mar 6, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

7 participants