Tidy 5e Sheet Rewrite Compatibility about magic-items-2 HOT 15 CLOSED

Update: I've now got the API ready with support for tab registration: https://kgar.github.io/foundry-vtt-tidy-5e-sheets/classes/Tidy5eSheetsApi.html#registerItemTab

There are probably more integration points I'll need to make to fully support integration from this module, but I'm here for it 👍

That being said, I heard the news about COVID. I hope you take care!

from magic-items-2.

This is exciting!

I will do my best to help out wherever able.

The tidy item sheet constructor name might change over time, so I have an API function that will insulate you from changes on my side:

from magic-items-2.

For the enabled() option, I recommend including the logic about GMs and hiding from players:

    enabled: (data) => {
      const isSupportedItem = ['weapon', 'equipment', 'consumable', 'tool', 'backpack', 'feat'].includes(data.item.type);
      const isAllowedToShow = game.user.isGM || !game.settings.get(CONSTANTS.MODULE_ID, 'hideFromPlayers');
      return isSupportedItem && isAllowedToShow;
    },

When false, it will not render the tab.

from magic-items-2.

I have some more ideas for you as I am reading and testing...

In the render() function on magicitemtab.js, could the show/hide logic and the enabled/disabled logic be done in the handlebars template itself? Since you are already using a Handlebars template, you can fully leverage its features to eliminate manual jquery show/hide/enable/disable post-processing.

The handleEvents() function on magicitemtab.js, I would recommend moving that logic down into the MagicItem class via the updateItem hook. You can inspect the item's flag data now that it has been updated, and you can update the MagicItem props accordingly. The benefit here is that you have direct access to your data in the flag, and you do not have to search for your data fields in the HTML. Also, any changes to the HTML should be triggering a re-render by default, so calling render again should hopefully be not needed.

If you need to transform any of the incoming data, I think you can leverage the preUpdateItem hook to review the data and backfill / transform any flags that are not in the right format:

If these suggestions work as I think they will, you wouldn't even need a MagicItemTab.bind() call for Tidy sheets. Then, you could remove Tidy-specific code from your MagicItemTab class, keeping it free of my module's influence 😅

from magic-items-2.

Link to the issue on Tidy 5e Sheet Rewrite Project

from magic-items-2.

https://github.com/PwQt/magic-items-2/tree/30-tidy-5e-sheet-rewrite-compatibility created a branch and started work on it,

Currently managed to somewhat show the sheet,
TODO:

• DragDrop functionality
• for some reason this radioBoxes throws an exception that something is undefined

<div class="form-group magic-item-sort">
        <label>{{localize "MAGICITEMS.SheetSortingMode"}}</label>
        <div class="form-fields" style="justify-content: flex-end">
            {{radioBoxes "flags.magicitems.sorting" sortingModes checked=sorting localize=true}}
        </div>
    </div>

• probably more template adjustments
• template doesn't receive the default values - Charges are NaN

from magic-items-2.

I've got the branch open on my side and am trying some things out. I should have some ideas in a day or so.

from magic-items-2.

Here's something I found:
If you'd like to use the magic item data for your handlebars-based tab, you can use the getData() option on the tab registration:

    getData: (data) => {
      return new MagicItem(data.item.flags.magicitems);
    },

This may not be the solution to the problem, considering the Magic Item is meant to exist on the MagicItemTab for a long time. However, this is an example of getting the data into the handlebars template.

from magic-items-2.

Here's something I found: If you'd like to use the magic item data for your handlebars-based tab, you can use the getData() option on the tab registration:

    getData: (data) => {
      return new MagicItem(data.item.flags.magicitems);
    },

This may not be the solution to the problem, considering the Magic Item is meant to exist on the MagicItemTab for a long time. However, this is an example of getting the data into the handlebars template.

If I understand the workflow right now it's:
-create the template,
-then do the onRender method?

That's why it's throwing an undefined on the radioBoxes, because it's expecting something to be there?

That's why i'm not a JS dev day-to-day 😅 - i overtook it from, and the module took off while i'm still learning how JS works.

from magic-items-2.

Here's something I found: If you'd like to use the magic item data for your handlebars-based tab, you can use the getData() option on the tab registration:

    getData: (data) => {
      return new MagicItem(data.item.flags.magicitems);
    },

This may not be the solution to the problem, considering the Magic Item is meant to exist on the MagicItemTab for a long time. However, this is an example of getting the data into the handlebars template.

If I understand the workflow right now it's: -create the template, -then do the onRender method?

That's why it's throwing an undefined on the radioBoxes, because it's expecting something to be there?

That's why i'm not a JS dev day-to-day 😅

Ah, welcome to the JS foundry module dev world! I've been here for about 6 months. It is a lot of fun, but there's a lot to learn, whew.

I would love to assist you to a greater degree if you would like, and I can share any knowledge I've gained along the way. If there is a better way to reach you, such as discord or some other chat, I can send more frequent info. Also, I can just post here if you'd like.

For now, let me answer the workflow question. For my sheets, they are running on totally different web tech, so I have to provide a layer of compatibility for handlebars. Here's what my sheets are doing:

• Confirm the template exists and compile it (path)
• Check if the template is enabled for this item at this time (enabled())
• Get any data for the handlebars template (getData())
• Render the template to the sheet body where the tab contents should go
• Allow the caller to react to the render event (onRender())

Technically, onRender() is only necessary if you need to wire up extra event handling, like if you were to do custom drag and drop handling or some other events that simple input changes do not cover.

In terms of simple data entry, show/hide logic, and enable/disable logic, the Handlebars template can typically cover all of that.

from magic-items-2.

If you are ok with it, I can PR to this branch some refactors to help smooth things out for compatibility wiring.

from magic-items-2.

If you are ok with it, I can PR to this branch some refactors to help smooth things out for compatibility wiring.

Sure, go for it, i planned on sitting some more on it sometime before the weekend.

from magic-items-2.

Thanks. I will have you some changes in a day or two. I've got a full list of goals and progress on the drafted PR #46

I can PR incremental changes to your branch so that we can collaborate and test together. It is all up to your preference as the module owner.

One question I have... How vital is hack()? I know what it does, but how important is it to you as the module author?
It is not harming my sheets module at all, but I think it has some potential issues when integrating with other modules.

from magic-items-2.

The "Items with Spells" library uses the standard sheet HTML for its spell table, so it inherits the default styles without much effort. I propose we do the same in MI2.

This commit demonstrates the alternate structure: 915c755

from magic-items-2.

Hey friends 👋

I have completed my changes for Tidy compatibility. To provide some of the hooks, selectors, and APIs for accomplishing some of the tasks in this process, I released a new version of Tidy 5e sheets, v0.2.16.

In the pull request #46 , I made a handful of simplifications which resulted in possibly fixing #37. I have tested it myself, but maybe someone else can take a look with my changes to confirm.

In the process of standardizing some of the list item table HTML, original Tidy's styles got messed up. Because original Tidy is hopefully retiring later this year, I have patched those broken styles in the MI2 module's CSS file, in the Tidy styles section. I also added styles for New Tidy where it made sense, in the same CSS file.

I found and fixed a number of issues with things parsing as NaN.
I resolved template errors and restored the radio buttons to their original functionality.
I made a number of properties static in places like the MagicItemSheet which needed to be shared.
I resolved some issues that arise when swapping sheets, where a Magic Item class would previously hold onto an instance of the sheet before it was swapped, leading to odd issues.

There's more I'd like to do to help out, but I think it would be better done outside of this one PR, after it's reviewed and vetted.

Latest Tidy Release:
https://github.com/kgar/foundry-vtt-tidy-5e-sheets/releases/tag/v0.2.16

from magic-items-2.