Change Log Types

[cpresler]

Added:

• Displaying change log types (uncommented and enhanced existing structure)
• Menu for selecting log type that is activated/deactivated by clicking on the default log type (added)
  • Menu indicates currently active type and does not update anything if existing type is chosen
• Move log type declaration into the types file and explicitly import/exported the related type declarations
• showTypeMenu added to ChangeLog type as an optional property to avoid breaking existing ChangeLogs that do not include it
• Property menu includes Log Types toggle for showing/hiding types on all change logs

Testing:

• create new FigLog - add change logs, modify their types
• "modify" a change log's type to the current type - should not show as edited, or have the edited time update
• modify change log types on existing FigLog instances without errors

[ryansrofe]

This is looking great. I love this new feature and we just had someone ask about it in the comments so great timing!

Some thoughts I had...

• Can we start with the dashed outlined "add type"
  • this will help with older versions as updating will make all logs start with the type added

• The first time they choose a type maybe we don't update the edited flag? If they update it again we should update the edited flag.

• If we click on the same log type maybe we close the menu instead of no action?

• Can we close the log type menu if we click outside it anywhere?

• If one log is open and we open another can we close the first one so there is only one log type menu open at a time?

[cpresler]

• Can we start with the dashed outlined "add type"
  • this will help with older versions as updating will make all logs start with the type added

I can definitely add the "add type" dashed version to the log types and start out all new logs with that type, but all existing ones already have "added" set as their type - it is included in Widget.tsx line 29 on main

• The first time they choose a type maybe we don't update the edited flag? If they update it again we should update the edited flag.

Sure, I should be able to make it so that changing from "add type" to something else doesn't trigger an "edited" change.

• If we click on the same log type maybe we close the menu instead of no action?

Good catch! This is a bug - I intended for it to close the menu.

• Can we close the log type menu if we click outside it anywhere?

I'll investigate if we can add dynamic onclick functionality to the rest of the widget without it messing with the ability to click on things generally.

• If one log is open and we open another can we close the first one so there is only one log type menu open at a time?

I'll have to include running through all other logs and setting their showTypeMenu props to false - this could have performance implications with a really large number of logs (like 1000+), but probably that is fine.

[ryansrofe]

one other ordering change in the property menu if we can, let me know if you think this order feels better and visually looks better with all the blue highlights.

Set Status | Name | Description | Version | Log Types | Branding

[cpresler]

I'm fine with changing the property menu order. I'll make that update as well!

[ryansrofe]

Noticing when the type is add type the type menu has a dashed border, when another option is chosen the border is solid. Can we use the solid border only?

[cpresler]

Noticing when the type is add type the type menu has a dashed border, when another option is chosen the border is solid. Can we use the solid border only?

Should be possible. That is a bug I hadn't noticed. Give me a few minutes to fix it

[ryansrofe]

Testing results from me. I created three widgets using the currently released widget. Then updated the version to that in this branch. All widgets updated as expected with little to no change in UI other than propertyMenu order. Log types work as expected and older logs start as add type.

[ryansrofe]

Does changing this, ugh my fat fingers, possibly introduce this setting breaking on older logs?

[cpresler]

I don't think so, did you try turning the branding on/off for the ones that you created from main? It seemed fine on the ones I checked.
It is one of those things that I was actually confused was working in the first place because you correctly spelled the variable everywhere except that spot.

[ryansrofe]

👏 I didn't think we were able to do this without perf issues, thank you!

[cpresler]

It might have perf issues with a ton (~1000) logs since it loops through and sets state on each one, but there are probably other issues at that point anyhow.

[ryansrofe]

👍