-
Notifications
You must be signed in to change notification settings - Fork 715
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
Onboarding import facility - Mostly designs #9534
Onboarding import facility - Mostly designs #9534
Conversation
Build Artifacts
|
fdd325c
to
60dd14c
Compare
Designs look to spec, and I found 2 missed instances of the proper focus trap:
Question for @jtamiace (added a comment in Figma too): Wouldn't it make more sense that in case where there are devices detected at this step, the |
Radio button text should overflow to the next line, not be cut out with ellipsis. @marcellamaki Is that something that we should fix in the KDS component? |
@radinamatic - yes, this is something we should fix in KDS. I am going to work on putting together a KDS dev issues milestone in support of 0.16 for us to review before our retro. I think we have an open issue for this, but will double check! |
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.
Is it clear why the functions are bound when defined in the now moved to core syncTaskUtils module?
It is not clear to me, but overall reading through the code, I did find it easy enough to follow?
As for whether moving is a good idea, I think on a basic level, having the things in a core util is helpful after a certain point, but I don't know enough context of if there are cons to this. would defer to @rtibbles on that one.
My other comments are small and not blocking. Design/figma look good to me
|
||
export const TaskTypes = { | ||
REMOTECHANNELIMPORT: 'kolibri.core.content.tasks.remotechannelimport', | ||
REMOTECONTENTIMPORT: 'kolibri.core.content.tasks.remotecontentimport', |
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.
Not blocking: This is a bit nit-picky, and I can see that this was just a "move existing code" but if it's possible, would we have these be more like REMOTE_CHANNEL_IMPORT
without it being too much of a hassle? I think it would be a lot easier to read. If easier to keep as is, because these are in too many places, no problem though
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.
💯 no prob at all good idea
|
||
export const TransferTypes = { | ||
LOCALEXPORT: 'localexport', | ||
LOCALIMPORT: 'localimport', |
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.
Same as above
@@ -139,6 +147,15 @@ | |||
return availableLanguages[currentLanguage]; | |||
}, | |||
}, | |||
methods: { | |||
/* If the user is focused on a form element and hits enter, continue */ | |||
handleEnterKey(e) { |
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.
nice! not for now, but I do wonder if we should implement this more widely?
it is my personal number 1 pet peeve when typing in a text field that enter is not the same as continue (if I'm not focused on the button)
Yes I agree, and it looks like this is the layout for the other "Select network address" modals already existing in Kolibri. Made the change to all the modals for onboarding in Figma in case that's still helpful |
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.
.bind(null...
feels a little opaque.
Wonder if we could start to experiment with another way of sharing dependencies that doesn't overload the core API?
import bytesForHumans from 'kolibri.utils.bytesForHumans'; | ||
import { TaskStatuses, TaskTypes } from '../constants'; | ||
import commonCoreStrings from '../mixins/commonCoreStrings'; | ||
import taskStrings from '../mixins/taskStrings'; |
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 know it was like this when you got here, but for the taskStrings at least, the mixins module exposes an export for the function:
export function getTaskString(...args) { |
Which should avoid having to do an awkward destructing off the methods property of the mixin itself.
Would be good to do something similar for commonCoreStrings.
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 coreString
signature maps directly to $tr
a la (key : string, args: object)
rather than taking some arbitrary number of nameless args - I'll apply the same here to make it more readable / consistent with the other code.
The commonCoreStrings
pattern though for using it in JS is like:
import { coreStrings } from 'kolibri...commonScoreStrings'; // imports the created translator
coreStrings.$tr(...);
So maybe it'd be good to export a getter function there as well and unify the pattern altogether. In which case maybe I can move this to a separate issue re: strings things to do before release?
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.
Yeah, I think having the explicit args is better - might be good to open a follow up and hash it out there, yes. I can imagine there will probably be other things to consider before we start moving stuff around more!
[TaskStatuses.CANCELED]: getTaskString('taskCanceledStatus'), | ||
[TaskStatuses.CANCELING]: getTaskString('taskCancelingStatus'), | ||
[TaskStatuses.FAILED]: getTaskString('taskFailedStatus'), | ||
[TaskStatuses.PENDING]: getTaskString.bind(null, 'taskWaitingStatus'), |
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 does indeed work, but I wonder if just an inline anonymous arrow function might be more comprehensible?
() => getTaskString('taskWaitingStatus')
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.
🤦 good call :)
@@ -39,13 +39,13 @@ | |||
|
|||
<script> | |||
|
|||
import { FacilityTaskPanel } from 'kolibri.coreVue.componentSets.sync'; |
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.
How do you feel about experimenting with putting some common code (but not really core code) into a module inside packages/kolibri-common
or some such?
Should then be referenceable as kolibri-common/path/to/component
.
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 that would help lighten our default front-end bundle load at all with tree shaking, then I think it's a good call for sure. Otherwise I'd be hesitant to separate anything from the apiSpec since, in spite of it being a big monolith, is an easy thing to reason about and change - at least it is once it's clear the object maps to the aliased paths in imports.
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.
Yes - I think a fair amount of the code that is in the default frontend bundle falls into this category, so if we can experiment with this here, it would set us up to migrate more things out of the frontend bundle, and reduce the size considerably, I think.
605a14a
to
5640e81
Compare
@radinamatic I've addressed the comments above. Note that the solution to wrapping the radio button label requires overriding a default setting in KDS that KRadioButtons be truncated with ellipsis. @rtibbles all feedback is addressed - I went to address your comment re: the exporting the translator method along with the mixins and create an issue bit figured it'd be just about as quick to just do some of the work up front here #9588 Also, created new issue re: a common module here #9589 |
Both missed focus traps are now working well, and the rest of my comments addressed! 👏🏽
If I understood @marcellamaki correctly, we are going to address that in KDS before 0.16 is released. I'll wait for @pcenov to finish his round of testing to approve. |
Thank you @pcenov, I was mostly concentrated on keyboard navigation, and missed to report these string discrepancies. @nucleogenesis, note that all instances of the string I can also replicate the rest of the issues reported above: missing setup step, device name, string change in the third screenshot ( |
80bd8c7
to
361d502
Compare
…ity & Device. Mitigate issues with calling a translator before i18n is ready by partially applying the t8n fns to defer evaluation
…TaskUtils; remove dupe defs from device & facility constants.js
…ntication, handle clicks for data sync on evts, pass footer message to components
…nt on continue, wrap in OnbStepBase
… FacilityTaskPanel
…t is a form element
…nue buttons (ie, during import loading)
…d to avoid mid-import nav
… remove "account" from end
… devtools warning
…line being clipped issue
…ssing in sync componentset
361d502
to
6356f39
Compare
re: KRadioButton - You're right, this will be dealt with in KDS learningequality/kolibri-design-system#302 re: "Import learning facility - Missing device name, network and facility name values" - There are two forms of this message - the one shown on my side is for when there are multiple facilities so the facility name is mentioned in the message there. The one @pcenov shared is for when there is one facility on the device. re: Import learning facility - Missing device name, network and facility name values - fixed in ad797f8 re: string updates |
@radinamatic The following issues are still present in: https://buildkite.com/learningequality/kolibri-debian/builds/4738:
The facility name is displayed correctly now at the last step of 'Import learning facility, however the 'is' is missing: @nucleogenesis Will those be fixed here or should I report them as separate issues? |
We agreed with @nucleogenesis to open follow up issue to review the strings, so this should be good to go! 🎉 |
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.
Manual QA is looking good! 💯
Summary
onboarding-import-flow-designs.mp4
thingToTranslationMap
objects into functions that return objects but I did this first and feels like half-dozen in one hand and six in the other in this case.Not included in this PR because the main focus is applying designs
References
Fixes #9310
Reviewer guidance
Please walk through the flow OR watch the video above. If you get stuck, wipe your browser's local data and refresh the page.
Code review: FWIW I tried to make my commits pretty self-contained overall
Testing checklist
PR process
Reviewer checklist
yarn
andpip
)