goetzrobin / spartan

Cutting-edge tools powering Angular full-stack development.
https://spartan.ng
MIT License
1.22k stars 133 forks source link

refactor(table): rewrite `Table` #145

Open alexciesielski opened 6 months ago

alexciesielski commented 6 months ago

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

Which package are you modifying?

What is the current behavior?

Context can be found in Discord

What is the new behavior?

Does this PR introduce a breaking change?

Other information

As discussed in Discord, this fixes the issue of dynamically rendering columns using @for which caused errors in the underlying CdkTable.

This is basically a complete rewrite of spartan's table by basically copying Angular Material's implementation and replacing the mat prefixes with brn and hlm in their respective places and applying proper classes in the hlm parts. I hope I didn't miss any classes.

Usage is exactly like Angular Material's table.

One thing I'm not sure on is the mixed usage of brn and hlm components in the final consuming code. My preference would be to have a HlmTableComponent that simply extends the BrnTableComponent and just applies the same template and providers in its @Component decorator plus some Tailwind classes, as I implemented - but I'm open to your suggestions

And in regards to the documentation I was thinking of copying parts of Materials table docs and for the example code applying on of the stories' code?

Left to do:

goetzrobin commented 6 months ago

I'll try to find some time this weekend to look at this!

martinledl commented 1 month ago

Is there any progress on this? I am willing to help if someone lets me know how :)

goetzrobin commented 1 month ago

@martinledl unfortunately I haven't had the bandwidth to give this the attention it deserved. I would like to see if we can keep the current API surface to an extend and not necessarily force everyone to work at the same low level as the cdk. However, if the current implementation is too limiting I am open to revisit this material like approach