Implement BaseCard

[AllanOXDi]

Description

Issue addressed

Addresses #PR# HERE

Before/after screenshots

Changelog

• [#PR no]
  • Description: Summary of change(s)
  • Products impact: Choose from - none (for internal updates) / bugfix / new API / updated API / removed API. If it's 'none', use "-" for all items below to indicate they are not relevant.
  • Addresses: Link(s) to GH issue(s) addressed. Include KDS links as well as links to related issues in a consumer product repository too.
  • Components: Affected public KDS component. Do not include internal sub-components or documentation components.
  • Breaking: Will this change break something in a consumer? Choose from: yes / no
  • Impacts a11y: Does this change improve a11y or adds new features that can be used to improve it? Choose from: yes / no
  • Guidance: Why and how to introduce this update to a consumer? Required for breaking changes, appreciated for changes with a11y impact, and welcomed for non-breaking changes when relevant.

[#PR no]: PR link

Steps to test

1. Step 1
2. Step 2
3. ...

(optional) Implementation notes

At a high level, how did you implement this?

Does this introduce any tech-debt items?

Testing checklist

• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical and brittle code paths are covered by unit tests
• The change is described in the changelog section above

Reviewer guidance

• Is the code clean and well-commented?
• Are there tests for this change?
• Are all UI components LTR and RTL compliant (if applicable)?
• Add other things to check for here

After review

• The changelog item has been pasted to the CHANGELOG.md

Comments

[MisRob]

Could we have this in the BaseCard? It's part of the general card logic.

[MisRob]

Hi Allan, thank you, seems to go really well :)! I added few random notes.

One high-level note, during development I'd suggest adding unit tests for the following:

• heading tag is configurable (for example, if I set headingLevel to 3, then h3 gets rendered)
• headingLevel accepts only values 2-6 (throws warning if not satisfied)
• throws warning if neither title prop or slot has been used
• has the markup structure mentioned in the requirements

and perhaps you will locate some other scenarios. There's no need to unit test styles, focus states etc., KDS testing is currently limited rather to business logic and markup.

I haven't reviewed in detail areas that seemed to be work in progress. Let me know any time, also if you had any questions.

[marcellamaki]

Hi @AllanOXDi - looks like some great foundational work here! One small suggestion is that you could consider using <component> here to manage this, rather than write out each condition separately, just to have this be a little bit more concise.

I haven't actually tried to run this code, so it might need some adjustments, but as an example:

<component
  :is="'h' + headingLevel"
  v-if="title !== null"
>
  <a :href="to">
    <KTextTruncator :text="title" :maxLines="1" />
  </a>
</component>

I think this will work with semantic HTML, and not just custom components that are created within the repository, although there might be some edge cases so it would be good to double check the documentation here and not just take my word for it 😂

[AllanOXDi]

Thanks for the suggestion- I going to be trying it out and see

[AllanOXDi]

This has been moved to #625. Closing it