-
Notifications
You must be signed in to change notification settings - Fork 648
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
string cleanup and refactoring #5057
Comments
I would add too that the amount of extraneous data in the DevTools has gone up a lot, making them harder to read for me
I would like to see some effort in reducing the amount of extra data in devtools. |
yeah, it's true. Do |
We could use the new Vue observable method to manage some of the watched state (like the modality) without having to put it in the store. Could do a similar refactor to the dynamic styles as well. I think the issue with the strings is that the common strings are exposed as a huge computed prop, so that also inflates things. |
oh right - because it's a mixin. I see there's a feature request to have devtools be smarter about vuex module organization so if we keep leveraging modules, things may improve on their end also ... eventually: vuejs/devtools-v6#327 |
Some codes that might be able to be deleted:
|
@indirectlylit @rtibbles @jonboiser What I've Done You can see the results of the profiling here. Note that there are 5 sheets in that doc at the bottom - each sheet is a profile of the section it's named by. Thoughts As for Coach, there seems to be many some which are used in many places, but are not defined in commonCoachStrings (example: In all cases, this should be a solid guide for me to do the qualitative work regarding the criteria that Devon proposed - that is - making sure that the text is used consistently enough to deserve moving to a common string file. Next Actions
From there - I can proceed with refactoring according to the discussion Richard and Devon had in Slack regarding moving away from the mixins approach and using |
My impression from looking at your profiling code that it is matching based on key, rather than string content? This might be an issue as it may give false positives of repeated strings. For any future tooling, might be good to use the existing message extraction code that we have - happy to give insights into extending/modifying it for the needs outlined above. |
this work is done I believe! @nucleogenesis correct me if I'm wrong |
Observed behavior
0.12.0 has quite a bit of string-related tech debt:
crossComponentTranslator
was used/abused to allow components to use translated strings from other componentspreviewLabel
(a noun) vspreviewAction
(a verb)Expected behavior
crossComponentTranslator
by either moving the string to the new component or moving the string to a shared fileNote on common strings:
First, we should remove the use of computed props and mixins. Instead, we should use
$formatMessage(namespace, stringID)
. See discussionSecond, we should be judicious about what strings are put in 'common' files because over-doing this can have adverse affects. In particular, sometimes strings that are the same in English actually need to be translated differently in other languages. For example:
Therefore, we should not put a string in common unless it is:
commonCoachStrings
User-facing consequences
none, but affects the costs and difficulty for devs and transators
Context
0.12.0
The text was updated successfully, but these errors were encountered: