feat(Table): generic table #1446
Conversation
…77f1 (#1405) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
- convert component to use `script setup` syntax to prepare for generics support - prop definition can't use local vars w/ `script setup`, set defaults to undefined & use `defu` to merge defaults where applicable - props mapped as local vars should overwrite direct prop references in the template - modify `loadingState` & `emptyState` computed properties, if the corresponding props are explicitly set as `null` they will pass `null` to maintain existing functionality - cast `rows` prop to a new generic type that extends a basic object representation - TODO: consider using `keyof Row` type on column keys to enforce type on internal functionality (need to solve for custom `action`-like columns)
|
I'm sorry you went through the trouble of refactoring all of this but this will be part of the |
|
That's fine, I mostly wanted to provide an example of how a generic implementation might look within the context of the library to advocate for it's inclusion in v3 and offer my assistance in it's development. I would like to see every component take advantage of generics where it makes sense. I probably could have just linked the branch in the issue instead of opening a PR, let me know if there is a better way to share proof-of-concept code like this and I will use that method in the future. |
|
Thanks for providing an example, I'll keep this in mind when refactoring the components 😊 |
|
I appreciate the work on Genetic types 🙏 |
🔗 Linked issue
Resolves #818
❓ Type of change
📚 Description
This PR converts the
tablecomponent to usescript setupsyntax to take advantage of generic types. The refactor involved some changes to properties formerly passed todefineComponentthat now needed to be defined w/ utility functions (defineOptions/useAttrs/ etc).The biggest change involved how prop defaults are handled due to the inability to reference local vars in the declaration. The PR inverts the current process by applying the defaults after props are defined rather than before, w/ the props defaulting to
undefinedwhich is automatically ignored bydefutherefore the mapped local vars will inherit values from the defaults.Mapping the results to local vars should mean that the
templatewill use those mapped values rather than the one inprops. However, this caused conflict w/ some computed props that were slightly renamed and then modified to use the local vars but still checkingpropsto see if the user explicitly sets asnull.The only other thing to note is that the column key could optionally by typed as
keyof Rowrather thanstring, but this will create type conflicts for any user that adds custom column keys likeactionin the examples so it was avoided. We could consider adding astring | keyof Rowtype but the benefits of this are negligible unless we introduce a mechanism that allows the user to explicitly extend the available keys in the type.The library is designed to support components that use the
defineComponentsyntax so this additional feels out of place in contrast w/ the other components but it could serve as a POC for a broader implementation of generics that I think could improve the DX and might be worth building into v3.📝 Checklist