Skip to content
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

Merged
merged 22 commits into from
Jan 14, 2023
Merged

Conversation

bluestrat404
Copy link
Contributor

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

Added Boxes theme scss and included a Boxes theme preview on the dev preview page.
@coveralls
Copy link

coveralls commented Dec 28, 2022

Coverage Status

coverage: 100.0%. remained the same
when pulling d740e85 on bluestrat404:Add-Boxed-Theme
into 6520c32 on no-chris:master.

Copy link
Owner

@no-chris no-chris left a 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.

.gitignore Outdated Show resolved Hide resolved
@import './common';

.cmTheme-boxes {
@page {
Copy link
Owner

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.

Copy link
Contributor Author

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.

packages/chord-mark-themes/yarn.lock Outdated Show resolved Hide resolved
@no-chris
Copy link
Owner

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.
@bluestrat404
Copy link
Contributor Author

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!

@bluestrat404
Copy link
Contributor Author

bluestrat404 commented Dec 28, 2022

This is how I would approach the section wrapping.

It's not the most elegant way but I think the most straightforward

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:

<p class="cmLine"><div class="cmSection">...</p>
<p class="cmLine">...</p>
<p class="cmLine">...</div></p>

What we need is:

<div class="cmSection">
  <p class="cmLine">...</p>
  <p class="cmLine">...</p>
  <p class="cmLine">...</p>
</div>

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 {
Copy link
Owner

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...

packages/chord-mark-themes/yarn.lock Outdated Show resolved Hide resolved
@no-chris
Copy link
Owner

no-chris commented Dec 28, 2022

orry 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.

You are doing great no worries 💪🏻

My next thought is that we may need a function "renderAllSections()" which calls renderAllLines(), instead of renderAllLines() being used directly by customRenderer/songTpl.

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.

For my suggestion, I was thinking that as soon as you have a section label line, then you should have an opening tag too, so the section label template would be updated. It could also include the closure of the previous section if this needs to be, by passing a parameter to the template. Then how to close the last section I'm not sure. Maybe it could be done systematically? So even if a section is not explicitly declared on the first line, we would create a cmSection wrapping for it, meaning that the markup would always contain a section. Well, I'm not sure and I don't have all the details sorted out in my head but I think it could be managed with the current loop.

Oh right I get it, the line wrapper is actually done after, forgot about that 🤦🏻

@no-chris
Copy link
Owner

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 renderLine() could be adapted. That feels like a hack but I'm afraid of the hidden complexity of going the other route

@no-chris
Copy link
Owner

no-chris commented Dec 28, 2022

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.
@bluestrat404
Copy link
Contributor Author

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.
@bluestrat404
Copy link
Contributor Author

Chris,

Here's one way to do it. Let me know your thoughts. And, happy new year!

-Adam

Copy link
Owner

@no-chris no-chris left a 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

packages/chord-mark/src/renderer/components/renderSong.js Outdated Show resolved Hide resolved
packages/chord-mark/src/renderer/components/tpl/song.js Outdated Show resolved Hide resolved
packages/chord-mark/src/renderer/components/tpl/line.js Outdated Show resolved Hide resolved
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
Copy link
Owner

@no-chris no-chris left a 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

packages/chord-mark/src/renderer/components/renderSong.js Outdated Show resolved Hide resolved
shouldOpenSection: opensSection,
sectionClasses: sectionWrapperClasses,
shouldCloseSection: closePriorSection,
closesFinalSection: shouldCloseFinalSection,
Copy link
Owner

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,
}

Copy link
Contributor Author

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.

packages/chord-mark/src/renderer/components/tpl/line.js Outdated Show resolved Hide resolved
packages/chord-mark/src/renderer/components/tpl/line.js Outdated Show resolved Hide resolved
packages/chord-mark/src/renderer/components/tpl/line.js Outdated Show resolved Hide resolved
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.
@bluestrat404
Copy link
Contributor Author

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.
Copy link
Owner

@no-chris no-chris left a 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().

👍🏻

Removed unnecessary/dangerous logic. I.e., made the tests appropriately dumber.
no-chris
no-chris previously approved these changes Jan 10, 2023
Copy link
Owner

@no-chris no-chris left a 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.
@bluestrat404
Copy link
Contributor Author

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.

@no-chris
Copy link
Owner

Thanks for your work, this is a nice improvement to ChordMark!

@no-chris
Copy link
Owner

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

bluestrat404 and others added 2 commits January 11, 2023 16:08
Include "cmSection" and "cmSection-xxx" classes.
@no-chris
Copy link
Owner

The build is failing because of 2 eslint errors
run yarn run lint (or npm run lint depending on which one you are using) from the root directory to see which ones. For the one related to allLines, just remove the parameter as the function already has access to allLines from where it is declared.

also please run prettier (you might also be able to configure your IDE to automate this) with yarn run format

Thanks!

@no-chris
Copy link
Owner

Also, to avoid merge confliicts, you don't need to commit the bundles:
packages/chord-mark/lib/chord-mark.js.map
packages/chord-mark/lib/chord-mark.js

Bundling is typically done before releasing as a separate step

@no-chris no-chris self-assigned this Jan 12, 2023
@no-chris no-chris added the breaking Breaking changes label Jan 12, 2023
@bluestrat404
Copy link
Contributor Author

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-chris
Copy link
Owner

No need to rollback the changes I've resolved the conflict

@no-chris
Copy link
Owner

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.
@no-chris no-chris merged commit 392b8e3 into no-chris:master Jan 14, 2023
@no-chris
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Breaking changes
Projects
Status: Archive
Development

Successfully merging this pull request may close these issues.

3 participants