-
Notifications
You must be signed in to change notification settings - Fork 61
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
Replace generated complex CSS with handcrafted CSS #291
Replace generated complex CSS with handcrafted CSS #291
Conversation
--------- Co-authored-by: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com> Co-authored-by: lpardosixtosMs <94007365+lpardosixtosMs@users.noreply.github.com>
@rniwa @bgrins @flashdesignory PTAL. This looks like a big change, but it is mostly refactoring and adding things to the complex DOM, the most important files to review are We still need to remove the extra class names that we previously added to the standalone versions, but we can do it in a follow up PR. |
From a high level this looks like a good change. In addition to being a simplification, having the rules apply visual effects (like prioritized items) is an improvement. I haven't gone through all the CSS in the PR but wanted to signal support from a first pass review. |
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.
Didn't run it locally, but changes make sense
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 also looks reasonable to me.
resources/todomvc/architecture-examples/angular-complex/scripts/build.js
Outdated
Show resolved
Hide resolved
resources/todomvc/architecture-examples/angular/src/app/todo-list/todo-list.component.html
Show resolved
Hide resolved
* Move reused logic into buildComplex Util function * Update build scripts
fs.copyFileSync(sourcePath, targetPath); | ||
} | ||
|
||
if (cssFilePath) { | ||
// get the name of the css file that's in the dist, we do this because the name of the css file may change | ||
const cssFile = fs.readdirSync(path.join(callerDirectory, sourceDirectory, cssFolder), { withFileTypes: true }).find((dirent) => dirent.isFile() && cssFileNamePattern.test(dirent.name))?.name; |
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 can see that this project is ignored by eslint and prettier (see .eslintignore and .prettierignore), it would probably be good to not ignore the handcrafted files such as this one and the others such as the handcrafted CSS file.
Could you either add the handcrafted files or ignore just the generated files, and run the formatter?
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'm good if you want to do this in a follow-up to more clearly distinguish the concerns.
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.
IIUC this project is not ignored, both the rules added to the .prettierignore and .eslintignore both start with "!".
I also see these files in the output when I run the formatter.
I can remove the rules I added previously in a follow-up since they aren't needed and I already have a follow-up PR in the works.
!/resources/todomvc/big-dom-generator
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 right I got confused.
Our project's prettier is configured with printWidth: 250
. I find this too long and got confused by this long line, but looks like this is accepted by prettier then...
Maybe you could split it up a bit still, up to you.
cssFilePath, | ||
cssFolder = "", // sometimes the css file we are looking for may be nested in another folder. | ||
cssFileNamePattern, // The css file name pattern is used to find the css file in the source dist directory. |
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.
maybe write clearly in a comment that cssFileNamePattern is mandatory if cssFilePath is present? Maybe it could even be good to check this in the code and throw an intelligible error if that's absent, but I'll let you choose if you want to implement this improvement.
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.
Will include in the follow-up which touches these files, I like the improvement.
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.
r+ with these changes
Thank you everyone for your reviews, merging this now. |
We are replacing the current auto-generated CSS rules for the complex DOM with a smaller number of handcrafted rules (see supporting doc.
Changes to the complex DOM generator:
big-dom-generator/src/app.css
.big-dom-generator/utils/app.css
Changes to the standalone version:
data-priority
attribute to the todoMVC list items that will be used to provide additional styling using new handcrafted CSS.Changes to the complex versions:
Hosted version (with all complex todoMVC variations enabled): https://lpardosixtosms.github.io/SpeedometerComplexHandcraftedAll/?developerMode=&tags=todomvc&measurementMethod=timer#home