Use the testcase widget for the $reveal widget examples

[btheado]

Translate the $reveal examples to use the $testcase widget.

Directly used the $testcase widget rather than test case tiddlers so the user can interactively click the buttons to see the behavior.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
tiddlywiki5	✅ Ready (Inspect)	Visit Preview	Jul 21, 2024 6:39pm

[Jermolene]

Thanks @btheado – sorry if I'm missing something obvious, but why can't these examples use separate testcase compound tiddlers?

[btheado]

I was thinking the testcase compound tiddlers required the expected results which don't seem to mean much for interactive examples. It would only show that the initial rendering is correct, but not actually verify the intended interactive behavior. Maybe I need to check this assumption.

Compare to this pending PR where I do use testcase tiddlers: #8376

[Jermolene]

Hi @btheado if the "ExpectedResults" tiddler is omitted then the testcase widget will not perform the test result checks. However, we might need to check in case the jasmine runner objects

[btheado]

OK, thanks. I'll play around with these examples as testcase tiddlers and see what happens.

[btheado]

Ok, I misremembered. It wasn't that the Expected Results were required is was that the view template didn't activate unless one of the $:/tags/wiki-test-spec tags were present. It didn't make sense to me to add that tag when no automatic test verification was taking place.

If you prefer to use the $:/tags/wiki-test-spec for these cases, that's fine with me. I admit it is nicer to have the examples factored out into separate tiddlers rather than inline, as that makes them reusable.

I didn't check yet how the jasmine runner behaves, but worst case, such tiddlers don't need to go into the tiddlers/testcases subdirectory. That way jasmine won't even see them.

[btheado]

I converted to testcase tiddlers. The jasmine runner treated the tests without ExpectedResult as passing tests and it worked fine. However, I figured it wouldn't hurt to add ExpectedResult of at least the initial rendering and so I did.

[btheado]

One point of friction with test case tiddlers is that editing via node.js causes the .tid extension to be removed and an extra .meta file to be created.

I suppose that is due to (from Customising Tiddler File Naming):

The default file extension of .tid is used for tiddlers that are missing the type field, or for tiddlers of type "text/vnd.tiddlywiki". Tidders of other types are saved according to their MIME types (defined at boot startup).

I haven't yet figured out how to change that for text/vnd.tiddlywiki-multiple.

[btheado]

I haven't yet figured out how to change that for text/vnd.tiddlywiki-multiple.

It worked to create a tiddler $:/config/FileSystemExtensions with this content:

[type[text/vnd.tiddlywiki-multiple]then[.tid]]

[Jermolene]

It worked to create a tiddler $:/config/FileSystemExtensions with this content:

Thank you @btheado I think that would be worth another PR to explore solutions for this. We can't ship $:/config/FileSystemExtensions as part of the core because it will be overwritten by any user settings.