-
Notifications
You must be signed in to change notification settings - Fork 3
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
Added Boxes Theme SCSS #586
Conversation
Added Boxes theme scss and included a Boxes theme preview on the dev preview page.
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.
Since it's a print-focused theme, what about calling it simply print2
?
I can see how wrapping the sections would be useful for theming, it should be easy enough. I'm just a bit afraid that breaking the rule that the root container's children are lines might break some unit tests that relies on this assumption.
As for the classes name I would suggest using a generic cmSection
for all sections and then a cmSection-xxx
where xxx
is the section label itself, e.g. cmSection-intro
, cmSection-chorus
, etc.
@import './common'; | ||
|
||
.cmTheme-boxes { | ||
@page { |
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 not sure about this. With the other print theme, margins are managed directly by Chord Charts Studio and not the theme itself.
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 handling it in Studio probably makes more sense. If we need a margin slider there, it could be added.
This is how I would approach the section wrapping.
It's not the most elegant way but I think the most straightforward |
Removed additions from local build.
Undoing changes from local build.
Fully reverted now — should've done this automatically not manually.
Updated theme name to Print 2 — and updating the other print to Print 1 to conform to the Dark # naming scheme. And reverted all changes from building locally. Also removed page margin from theme, as that can be handled elsewhere.
…rd-mark into Add-Boxed-Theme
Sorry for spamming commits there. Can you tell I'm a bit of a Github newb?? The final commit has all the changes from your review here — I think. I like your suggestions as to cmSection. Thanks! |
This would be the most straightforward, but since each line is a <p> I can't think of how to do what's needed here, which would be to wrap all the <p class="cmLine">s of a section within <div class="cmSection">...</div>. That is, the below wouldn't work as HTML:
What we need is:
My next thought is that we may need a function "renderAllSections()" which calls renderAllLines(), instead of renderAllLines() being used directly by customRenderer/songTpl. Doing it this way, while more of a pain, should be better for writing tests, too, right? Let me know if I'm overcomplicating it. Adam |
@@ -1,7 +1,7 @@ | |||
@import '../abstract'; | |||
@import './common'; | |||
|
|||
.cmTheme-print { | |||
.cmTheme-print1 { |
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 is a breaking change as all client code using this theme would have to update. I'm not aware of any application beside Chord Chart Studio but maybe it's better to avoid it?
Although I'm thinking that in any case, the markup change will also be a breaking change...
You are doing great no worries 💪🏻
That would be the more elegant way of doing it indeed, but I think more complex. Feel free to give it a go if you feel like it.
Oh right I get it, the line wrapper is actually done after, forgot about that 🤦🏻 |
Grouping lines by sections is something I already did for the ChordPro converter:
I would still try to avoid going there in the main rendering function Maybe |
For example: const wrapperClasses = ['cmSection', 'cmSection-intro'];
return renderLine(rendered, {
isFromSectionMultiply: line.isFromSectionMultiply,
isFromAutoRepeatChords: line.isFromAutoRepeatChords,
isFromChordLineRepeater: line.isFromChordLineRepeater,
isFromSectionCopy: line.isFromSectionCopy,
shouldOpenWrapper: true,
wrapperClasses,
shouldCloseWrapper: true,
}); parameters could use better names |
Changed theme "Print 1" back to "Print", and removed empty line at end of yarn.lock.
Thanks for your graciousness and thoughts. I've committed a fix for the yarn.lock and to roll "print1" back to "print". I like your idea to hack renderLine rather than introduce a bunch of extraneous new logic. I'll work on that next. |
This change wraps sections in <div>s for theme styling. This could be done in a few ways — this way adds some simple logic to renderAllLines in renderSong.js (and related files). The print2.css theme is also updated here slightly.
Chris, Here's one way to do it. Let me know your thoughts. And, happy new year! -Adam |
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.
Happy new year! Thanks for that, I've added a few comments
Addressing review comments here: 1. Created function getSectionWrapperClasses 2. Added logic to renderAllLines (and associated) so as not to spawn a needless div. 3. Eliminated repetition in tpl/line.js
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! Expect some nitpicking in the comments but this looks good.
Now 2 extra challenges 😅
- I've updated the
master
branch this morning so you will need to pull the changes locally in your branch (git pull origin master
) - the new feature needs to be covered by unit tests. Luckily most assertions are made against strings and not the html markup so hopefully this should not break a lot of tests. We need at least to update:
- the renderLine() unit test to check that the proper markup is created based on the given parameters
- the renderSong() unit test to check that the main rendering loop is properly filling those parameters
Unfortunately the bulk of the unit test suite is not checking the html markup because most of the rendering logic can be assessed by checking at the rendered text nodes, so I don't have any good example to share on how to test the markup itself. Let me know if you need help
shouldOpenSection: opensSection, | ||
sectionClasses: sectionWrapperClasses, | ||
shouldCloseSection: closePriorSection, | ||
closesFinalSection: shouldCloseFinalSection, |
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.
We can greatly simplify this by aligning variable names with parameter names:
{
...
shouldOpenSection,
shouldCloseSection,
shouldCloseFinalSection,
sectionWrapperClasses,
}
and actually I'm thinking that we may be able to simplify further by removing some local variables
{
...
shouldOpenSection,
shouldCloseSection: shouldOpenSection && lineIsInASection,
shouldCloseFinalSection: isLastLine(allLines, i) && lineIsInASection,
sectionWrapperClasses,
}
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. I think the problem with ( shouldOpenSection && lineIsInASection ) for shouldClosePriorSection is that we need the last iteration's value of lineIsInASection. That was my thought with the shouldClosePriorSection variable — effectively to store whatever that lineIsInASection value was before we change it now that we know we're in a section.
Simplifying code based on review. Unit tests will come next.
Added unit tests to check that renderLine creates the proper markup based on the given parameters.
Adding one more test case: a final line that is its own final section.
Better of the description of the final test.
Slight tweak (again) to renderLine test case name. Added test "Wrap Sections in Divs > correctly create and class sections" to renderSong.
It turns out it hadn't broken any tests, so that's good. My latest commit adds a test for renderLine() using regex to check the markup. That may be more strict than needed or wanted, but it works, and I'm proud of it as the first test I've ever written. I'm sure it can be improved on. It also adds the test for renderSong(). Let me know. |
Fixed a typo: sectionWrapperClasses should've been an array length 2, not a string with a space in it.
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.
It turns out it hadn't broken any tests, so that's good.
I'm not sure whether that's a good thing or not, but at least it does make things easier 😅
My latest commit adds a test for renderLine() using regex to check the markup. That may be more strict than needed or wanted, but it works, and I'm proud of it as the first test I've ever written. I'm sure it can be improved on.
Very nice for a first test, you should be proud indeed! 👏🏻 I have a few comments for improvement.
It also adds the test for renderSong().
👍🏻
packages/chord-mark/tests/unit/renderer/components/renderLine.spec.js
Outdated
Show resolved
Hide resolved
packages/chord-mark/tests/unit/renderer/components/renderLine.spec.js
Outdated
Show resolved
Hide resolved
packages/chord-mark/tests/unit/renderer/components/renderSong.spec.js
Outdated
Show resolved
Hide resolved
Removed unnecessary/dangerous logic. I.e., made the tests appropriately dumber.
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 looks good, congrats! 👏🏻
I'll merge this in the next few days
Minor simplification to renderLine. In renderSong, add test to ensure no extra markup is created if no sections are given.
Thanks for all the help and feedback! I look forward to getting the second print theme option going in Chord Chart Studio. I've started looking through the code. |
Thanks for your work, this is a nice improvement to ChordMark! |
Oh, I forgot, the classes list needs to be updated in ChordMark's Readme. No need to detail all possible sections, cmSection-xxx is fine there too |
Include "cmSection" and "cmSection-xxx" classes.
The build is failing because of 2 eslint errors also please run prettier (you might also be able to configure your IDE to automate this) with Thanks! |
Also, to avoid merge confliicts, you don't need to commit the bundles: Bundling is typically done before releasing as a separate step |
Fixed lint errors and ran prettier.
…rd-mark into Add-Boxed-Theme
Thanks! I've fixed the errors and ran prettier. Do I need to roll back the bundle changes now, or just not commit them in the future? |
No need to rollback the changes I've resolved the conflict |
Sorry I keep on adding new things 😅 There are some new styles that I've introduced with a recent feature you may, if you want, add them to your style as well:
|
Add cmSubBeatGroup opener and closer opacity change.
Merged! I released it as a beta until the rest of the functionality is fully implemented in Chord Chart Studio: https://github.com/no-chris/chord-mark/releases/tag/v0.13.0-beta.0 |
Hi Chris,
Here's a first stab at adding the theme scss. I'm not sold on "Boxes" as the title, but it works for now. I also included the theme preview on the dev preview page.
This doesn't yet draw the boxes like in that example file on the other thread, but it's ready to — see lines 20 and 29 of boxes.scss.
To get those boxes, we'd need to get the renderer to wrap sections in divs and give them class names like what I'm proposing here in those lines: cmSection and cmChorusSection.
What do you think?
Thanks,
Adam