Blocks: Fix demo teaser markup, More block custom text

[aduth]

This pull request seeks to resolve two issues with the More block:

• Fix incorrect syntax for the demo content core/more block teaser. Currently, the teaser tag is treated as freeform content, causing a freeform block to be unintentionally inserted after the More tag in demo content.
• Fix attribute naming for custom text (wrong: text, correct: customText)

Testing instructions:

Verify that when viewing the demo, the more block is shown with custom "Keep on reading!" text, that selecting the More block reveals "Teaser" is checked in the block settings, and that no freeform block is shown following the More block. Check that setting custom text to the More block, saving and reloading respects the changes made.

[codecov]

Codecov Report

Merging #2828 into master will increase coverage by 0.01%.
The diff coverage is 62.5%.

@@            Coverage Diff             @@
##           master    #2828      +/-   ##
==========================================
+ Coverage   33.78%   33.79%   +0.01%     
==========================================
  Files         191      191              
  Lines        5692     5693       +1     
  Branches      997      998       +1     
==========================================
+ Hits         1923     1924       +1     
  Misses       3189     3189              
  Partials      580      580

Impacted Files	Coverage Δ
blocks/api/serializer.js	98% <100%> (+0.08%)	⬆️
blocks/library/more/index.js	22.22% <25%> (-7.78%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2753f63...3ba6476. Read the comment docs.

[youknowriad]

I don't know if I'm doing something wrong but when refreshing the page, I lose the custom text (I see null) and the teaser option is not selected.

[aduth]

I don't know if I'm doing something wrong but when refreshing the page, I lose the custom text (I see null) and the teaser option is not selected.

Hm, yes, I can confirm this too. One half of this issue (not being serialized correctly) is fixed in 3a45620 .

But also, the "Null" text being shown stems from the fact that the PEG parser returns customText as null when not assigned, but our attribute sourcing only considers explicitly undefined in considering an attribute as "not assigned". Therefore, the null gets coerced to a string and shows verbatim. There are two options here:

• We can update the grammar to fall back to undefined if it parses as falsey: customText: customText || undefined
• We can update the attribute sourcing to consider both undefined and null as unassigned: null == value

Where this becomes more interesting is in how we align this with the PHP attributes behavior, where PHP only has the single concept of null, not null and undefined. In server-side rendering, we consider the null value as "not assigned". There is a distinction we can make in null vs isset in PHP, so perhaps we can emulate this by removing the null fallback in PHP and relying on isset to determine whether an attribute should apply the default value.

cc @dmsnell

[aduth]

In 8483b8a , I opted to update the PEG grammar to return falsey as undefined in the JavaScript implementation only, and for now not make any changes to either the PHP parse or treatment of attributes.

[aduth]

Also, it is fun to see that the test fixtures illuminate the issue, but only after the fix is applied 😆 (See core__more__custom-text-teaser.serialized.html)

[dmsnell]

was there any real change here other than the name of text vs customText? I ask because we changed the declarative return with an imperative mutating return 😉

[aduth]

The only effective difference should be the change in name from text to customText yes. I thought I might have made an improvement by refactoring the template+ternary soup but... well, we've been around this block before and I really don't care enough one way or the other to argue it 😄

[dmsnell]

I won't gripe if you make a change to prefer your style over mine in this case, but maybe there's a middle-ground.

const moreTag = text
	? `<!--more ${ text }-->`
	: '<!--more-->';

const noTeaserTag = noTeaser
	? '<!--noteaser-->'
	: '';

return compact( [ moreTag, noTeaserTag ] ).join( '\n' );

I'm a huge fan of ternaries (they are expressions and not statements like their cousins, the if structure) but I do draw the line at nesting ternaries.

[aduth]

maybe there's a middle-ground.

Looks good to me. Updated in rebased 3ba6476 .

[dmsnell]

thanks @aduth