fix(Team Dashboard): conditional visibility of buttons

[HenerHoop]

https://app.clickup.com/t/86ayqff97

[HenerHoop]

Task linked: CU-86ayqff97 Manage team roadmaps display conditionally

[github-actions]

size-limit report 📦

Path	Size
packages/cxl-ui/pkg/dist-web/cxl-ui.js	66.87 KB (+0.1% 🔺)
packages/cxl-ui/pkg/dist-web/cxl-ui-jwplayer.js	11.87 KB (0%)
packages/cxl-ui/pkg/dist-web/cxl-ui-playbooks.js	27.77 KB (0%)
packages/cxl-ui/pkg/dist-web/vendor.js	135.58 KB (0%)
packages/cxl-ui/pkg/dist-web/cxl-ui-jwplayer.js, packages/cxl-ui/pkg/dist-web/cxl-ui-playbooks.js, packages/cxl-ui/pkg/dist-web/cxl-ui.js, packages/cxl-ui/pkg/dist-web/manifest.js, packages/cxl-ui/pkg/dist-web/unresolved.js, packages/cxl-ui/pkg/dist-web/vendor.js	243.24 KB (+0.03% 🔺)

[anoblet]

This looks good :)

We should get into the practice of using the nothing sentinel (https://lit.dev/docs/api/templates/#nothing) as opposed to returning an empty string in ternaries. This means lit throws away the template part for future evaluations, a small performance boost.

[HenerHoop]

This looks good :)

We should get into the practice of using the nothing sentinel (https://lit.dev/docs/api/templates/#nothing) as opposed to returning an empty string in ternaries. This means lit throws away the template part for future evaluations, a small performance boost.

@anoblet Thanks for this information. I updated the code.

[pawelkmpt]

@HenerHoop please follow commit messages standard we use. Look and git log and see how it's usually done.

- fix(Team Dashboard): conditional visibility of buttons
+ refactor(cxl-ui): conditional visibility of buttons in team components

I'm actually surprised linter let you pass "Team Dashboard" in scope 🤔

[HenerHoop]

@HenerHoop please follow commit messages standard we use. Look and git log and see how it's usually done.

- fix(Team Dashboard): conditional visibility of buttons
+ refactor(cxl-ui): conditional visibility of buttons in team components

I'm actually surprised linter let you pass "Team Dashboard" in scope 🤔

@pawelkmpt But why is the logic of front (aybolit) and back-end(wpstarter) commits different? In one, you need to refer to a packet, and in the other, to a class/feature?

[pawelkmpt]

@pawelkmpt But why is the logic of front (aybolit) and back-end(wpstarter) commits different? In one, you need to refer to a packet, and in the other, to a class/feature?

They were developed separately and commit standards were set at different moments in time. Aybolit is also a fork from 3rd party developer and we followed what was defined there.

Worth mentioning, WPS became monorepo in the beginning of this year. Previously all items from packages directory were separate repositories. The best maintained was institute-plugin.

[HenerHoop]

They were developed separately and commit standards were set at different moments in time. Aybolit is also a fork from 3rd party developer and we followed what was defined there.

Worth mentioning, WPS became monorepo in the beginning of this year. Previously all items from packages directory were separate repositories. The best maintained was institute-plugin.

But could we standardize this logic?

[pawelkmpt]

But could we standardize this logic?

It ain't easy to standarize everything, but indeed it could be more explicit.

https://app.clickup.com/2317190/v/dc/26pw6-8023/26pw6-7161