-
Notifications
You must be signed in to change notification settings - Fork 691
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
Coach main navigation refactor #12775
Coach main navigation refactor #12775
Conversation
Build Artifacts
|
name: QuizSummaryPage.name, | ||
path: '/:classId/plan/quizzes/:quizId/:tabId?', | ||
name: PageNames.EXAM_SUMMARY, | ||
path: path(CLASS, QUIZ, '/:tabId?'), |
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 am planning to expand this path(...)
pattern, if there is any objections you can let me know :)
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 must admit, I don't particularly like it - but I can't quite put my finger on why (I didn't like its existing use in many different parts of the coach routing). I was hoping that we could use nested routes to do a lot of this sort of concatenation, but given the nature of the routing, I don't think we can.
So, I think this is fine - but I guess, is there any reason to not just do CLASS + QUIZ + '/:tabId?'
?
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 dont like it neither 😆, because for non-familiarized people its very tedious as we just cant inmediately see what is the actual path of each route. But for this refactor it was much easier to just remove the /plan
on the CLASS constant, and I think it ensures the consistency as we will need to rewrite the same base routes a huge lot of times. I'm not opposed to reverting it, But whatever pattern we choose, I would like to replicate in all the coach routes for consistency.
is there any reason to not just do CLASS + QUIZ + '/:tabId?'?
Not really, I can make this change.
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.
would like to replicate in all the coach routes for consistency
for me this is the most important thing.
I think my challenge with this existing routing pattern is that I find it a bit inconsistent within its own logic. For example in the reportsRoutes
const CLASS = '/:classId/reports'
feels inconsistent const QUIZ = '/quizzes/:quizId';
. I know it's necessary (it's the reports, not the plan tab), but it isn't really something you can logic out with normal API patterns when reading the code.
And that is not even including the differences in the files between reports and plan (which thankfully, will disappear with this refactor! 🎉)
I wonder if there might be some small changes that we could make to have these feel internally more consistent, without too much scope creep? That might help with making them easier to read. I can try to come up with some more concrete suggestions if either of you think this is worth talking about more (or an example, if this feels vague). Some of this might be resolved just in the course of getting rid of the reports and plan differences, I just haven't thought it all through yet.
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 maybe best to do the minimum for now in terms of the actual content of the routes, and then we can do smaller follow up issues for routes cleanup specifically.
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.
After migrating a huge amount of routes, I am glad we had these constants partial terms, it made everything much easier
kolibri/plugins/coach/assets/src/views/lessons/LessonSummaryPage/tables/LessonLearnersTable.vue
Outdated
Show resolved
Hide resolved
kolibri/plugins/coach/assets/src/views/lessons/LessonSummaryPage/ManageLessonModals.vue
Show resolved
Hide resolved
@@ -1,21 +1,23 @@ | |||
import { PageNames } from '../constants'; | |||
import { LessonsPageNames } from '../constants/lessonsConstants'; | |||
import routes from '.'; |
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.
The purpose of the baseRoutes is to avoid importing the full routes module into the CoachSideNavEntry module (which is an entry point in itself), as doing so will significantly increase the size of that bundle. So we should undo this import and update the paths in another way.
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.
Oooh, didnt know that, I just wanted to avoid the duplication of these routes. But if its because of performance reasons, I think its better just to revert it and keep the old strategy. At the end we wont be touching this file too much.
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.
If you want to have a single source of truth, you could put the path segments into a constants file and reference those in here (although that would be further obfuscating the actual paths in multiple places!)
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 having a single source of truth might be useful, but I have struggled quite a bit with some of the use of constants throughout the coach pages/routing. I know this refactor overall will help a lot with the parts of this plugin that are more confusing. But, I think if we do go the constants route (...that joke was just for you Richard), it might be helpful to have someone less familiar with the coach architecture in general take a look before approval/merge and see how easy it is for them to parse.
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.
But, I think if we do go the constants route (...that joke was just for you Richard)
This is a very thinly sliced double meaning.
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.
just added a few thoughts in the threads where you were talking to @rtibbles, @AlexVelezLl !
@@ -1,21 +1,23 @@ | |||
import { PageNames } from '../constants'; | |||
import { LessonsPageNames } from '../constants/lessonsConstants'; | |||
import routes from '.'; |
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 having a single source of truth might be useful, but I have struggled quite a bit with some of the use of constants throughout the coach pages/routing. I know this refactor overall will help a lot with the parts of this plugin that are more confusing. But, I think if we do go the constants route (...that joke was just for you Richard), it might be helpful to have someone less familiar with the coach architecture in general take a look before approval/merge and see how easy it is for them to parse.
name: QuizSummaryPage.name, | ||
path: '/:classId/plan/quizzes/:quizId/:tabId?', | ||
name: PageNames.EXAM_SUMMARY, | ||
path: path(CLASS, QUIZ, '/:tabId?'), |
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.
would like to replicate in all the coach routes for consistency
for me this is the most important thing.
I think my challenge with this existing routing pattern is that I find it a bit inconsistent within its own logic. For example in the reportsRoutes
const CLASS = '/:classId/reports'
feels inconsistent const QUIZ = '/quizzes/:quizId';
. I know it's necessary (it's the reports, not the plan tab), but it isn't really something you can logic out with normal API patterns when reading the code.
And that is not even including the differences in the files between reports and plan (which thankfully, will disappear with this refactor! 🎉)
I wonder if there might be some small changes that we could make to have these feel internally more consistent, without too much scope creep? That might help with making them easier to read. I can try to come up with some more concrete suggestions if either of you think this is worth talking about more (or an example, if this feels vague). Some of this might be resolved just in the course of getting rid of the reports and plan differences, I just haven't thought it all through yet.
e1dfbf4
to
cd788dc
Compare
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.
Just one immediate thing that sprung out to me.
My only other thought is whether there are any other components (I think the routes are unavoidable) that could be moves with edits rather than new components? That could make the diff a bit clearer in terms of what is actually updated here, and what has been created anew.
@@ -15,3 +15,31 @@ export function classIdParamRequiredGuard(toRoute, subtopicName, next) { | |||
return true; | |||
} | |||
} | |||
|
|||
export function useRouteTerms() { | |||
return { |
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.
This feels like it could just be a module level constant object rather than needing to be returned from a function? The composable seems unnecessary 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!
Hi @AlexVelezLl, I was able to identify the following issues, which I can also report separately if not in scope for this PR:
responsive.mp4
Edit.lesson.mp4
preview.quiz.mp4
delete.a.quiz.mp4
copy.quiz.and.go.back.mp4
classes.page.mp4 |
Thank you @pcenov!
|
I have fixed 2, 3 and 4 @pcenov :). 1, 5 and 6 are issues that also happen in develop so I think it will be better to have different issues for them. |
Thanks @AlexVelezLl - I confirm that 2, 3 and 4 are fixed now and I have filed follow-up issues for the rest. While regression testing today I noticed the following issues, which again if not caused by changes made here, I'll report separately:
export.lessons.mp4
|
Thank you @pcenov! I have fixed numbers 1 and 2. Number 1 was also happening in develop but just fixed this as this was a quick fix. Number 3 is part of a broader issue which is that in coach we dont have a not found or permissions error page in general, not as part of this PR, so I think this could be reported separately. |
Thanks @AlexVelezLl - I've verified that points 1 and 2 are fixed now and I didn't see any other issues while regression testing. |
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.
Hi @AlexVelezLl - this is good to go! I did add one non-blocking question, mostly because we have some ongoing to-dos about loading state in the coach plugin, and I want to be sure I'm paying attention to the changes here that might impact how we address that. Thank you!! This was a lot of work 😅 nicely done
export default [ | ||
{ | ||
name: PageNames.GROUPS_ROOT, | ||
path: path(CLASS, ALL_GROUPS), | ||
component: ReportsGroupListPage, | ||
handler: () => { | ||
store.dispatch('notLoading'); |
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.
Why did we remove this notLoading dispatch? I don't mean that you shouldn't have, just want to make sure I understand if this is connected to other changes and that I understand them
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.
Oh its because we already handle this in the showGroupsPage
store.dispatch('notLoading'); |
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.
thank you!
Summary
class
,plans
,reports
->class
,lessons
,quizzes
,learners
,groups
.LearnerQuizPage
,ExerciseQuestionListPage
andQuestionLearnersReport
components.Compartir.pantalla.-.2024-10-30.09_24_14.mp4
References
Closes #12729 and #12801
Reviewer guidance
For code review:
For QA:
Follow ups
Testing checklist
PR process
Reviewer checklist
yarn
andpip
)