Replies: 2 comments 1 reply
-
So, I'm thinking about a polymorphic way of doing this with tab registration classes. Something like: const tidyApi = game
.modules
.get('tidy5e-sheet')
?.api;
if (!tidyApi) {
return;
}
const myTab = new HandlebarsTab({
// Look for either a template path or a template string; either should be permissible; if you provide both, I take the string
templatePath: "path/to/template.hbs",
template: "<h2>Alternatively, just provide the Handlebars template directly? By the way, what's this app ID? {{appId}}</h2>",
// title: Localization keys also work
title: "My Tab Title",
// makeDefault: Makes this tab appear as a default tab in Tidy config settings
makeDefault: true,
// useCoreSheetListeners: not required, defaults to true for handlebars tabs, provides the stock Actor sheet functionality; e.g., expanding/collapsing item row previews
useCoreSheetListeners: true,
// onRender: optional, lets you do extra stuff to your tab contents at render time
onRender: (tabContentElement, context, force) => console.log('Do whatever I want with my tab contents', tabContentElement),
// ...?
});
tidyApi.registerActorTab(myTab); |
Beta Was this translation helpful? Give feedback.
1 reply
-
Yep, great talk, gang 😎 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This post is to discuss a structure for the API function(s) for registering tabs.
Why?
Tidy 5e Sheets have numerous features surrounding registered tabs, such as Tab Selection, Tab Ordering, and Default Tabs per Actor Type. To create a better user experience, having modules register their tabs will put power in the hands of the users when it comes to deciding which tabs to actually include on which sheets.
This rewritten version of Tidy 5e Sheets runs on svelte, so I do not have auto-magic jquery support for adding tabs and having them just work. Granted, I could mimic how the stock tab system works, but that would also tie my hands when it comes to providing various sheet layouts. I do not wish to be bound to the HTML structure and data-attribute requirements of the default sheets. So, these tabs may have different classes/selectors now or in the future as the sheets evolve. Providing a single way to register tabs is critical so that 1) module devs aren't having to scramble if the sheets' structure changes and 2) I am not having to tie my hands regarding evolving the sheets and offering additional layouts.
These sheets do not innately use the jquery listeners, so API support will be important for that also.
Use Cases / Ideas
Draft of API call(s)
Goals
Questions
Beta Test Rollout
Once there are solid options for Handlebars and HTML-based tab registration paths, I'll prepare a release. After that, I will do CSS work and bugfixing/changes.
I will be testing locally with modules mentioned by the Tidy 5e sheet community members so I can get a feel for what needs to be done.
When the API can be settled upon, I will start working on API documentation generation for this repo, as well as a type definitions npm package for convenience.
I Don't Own the Module ID Yet - How to Test the API anyway
Tip
Have both the original and the rewritten sheet modules installed and active.
Right now, original Tidy 5e and the rewrite can be compared side-by-side. This is meant to be a convenience for users so they do not have to uninstall/reinstall sheets to test out the rewrite. This presents a problem with providing an API directly on the module namespace 'tidy5e-sheet'. As a result, I am doing the following:
So, you can opt to call my alpha/beta-testing module ID, but if you have the original sheets and the rewrite sheets both installed and turned on, you can just call the original sheets' module ID and use the API for the rewrite. It's weird, but I'm doing this for the users' convenience while I'm still in this alpha/beta period with the rewrite.
My recommendation is to program against the original module ID ("tidy5e-sheet") with the two modules installed/active. That way, when it's time to take over the module ID, your module won't have to make any changes.
Documentation and Type Definitions
When the API comes together, I will be working on publishing type definitions as a standalone NPM/etc. package and providing generated API documentation on this repo.
Beta Was this translation helpful? Give feedback.
All reactions