Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overall type improvements #3707

Open
wants to merge 29 commits into
base: develop
Choose a base branch
from
Open

Overall type improvements #3707

wants to merge 29 commits into from

Conversation

ghsolomon
Copy link
Contributor

@ghsolomon ghsolomon commented Jun 28, 2024

Hoist P/R Checklist

Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

  • Caught up with develop branch as of last change.
  • Added CHANGELOG entry, or determined not required.
  • Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
  • Updated doc comments / prop-types, or determined not required.
  • Reviewed and tested on Mobile, or determined not required.
  • Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

cnrudd and others added 25 commits May 28, 2024 14:30
Made hoist components limit ref prop only to those setup to handle it.
Had forgotten to remove ref from ElementSpec.
# Conflicts:
#	CHANGELOG.md
#	core/HoistComponent.ts
#	core/HoistProps.ts
#	desktop/cmp/input/ButtonGroupInput.ts
# Conflicts:
#	CHANGELOG.md
#	core/HoistComponent.ts
CHANGELOG.md Outdated
@@ -13,15 +13,20 @@

## 65.0.0 - 2024-06-26

### 💥 Breaking Changes (upgrade difficulty: 🟢 TRIVIAL - dependencies only)
### 💥 Breaking Changes (upgrade difficulty: 🟢 TRIVIAL - dependencies and renamed component prop)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this release has sailed, will need to move these to next CL version entry

Copy link
Member

@amcclain amcclain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only read a little bit of the way through, but looks like a super in-depth and interesting change! I left a few comments with questions - will catch up again when I return after OOO

import {TEST_ID} from '@xh/hoist/utils/js';
import {splitLayoutProps} from '@xh/hoist/utils/react';
import classNames from 'classnames';
import {merge} from 'lodash';
import './Badge.scss';

export interface BadgeProps extends HoistProps, BoxProps {
export interface BadgeProps extends HoistPropsWithRef<HTMLDivElement>, BoxProps {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Realizing that I need to catch up with the ref handling I see we have throughout the toolkit. I had not realized that we were passing refs through on so many components, and I confess I don't know what the rules are here as to when / why we do that (or when/why app components should do the same).

@@ -145,7 +146,7 @@ export class FilterChooserModel extends HoistModel {
@observable.ref selectValue: string[];
@observable favoritesIsOpen = false;
@observable unsupportedFilter = false;
inputRef = createObservableRef<HTMLElement>();
inputRef = createObservableRef<HoistInputModel<null>>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious about the null passed to the generic here - what is that about / worth a comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made HoistInputModel generic to provide a type for the inputRef. In cases where that isn't being used, I thought it made sense to pass null since inputRef.current will always be null.

@@ -21,7 +21,7 @@ import {FormModel} from './FormModel';
/** @internal */
export interface FormContextType {
/** Defaults props to be applied to contained fields. */
fieldDefaults?: Partial<BaseFormFieldProps> & DefaultHoistProps;
fieldDefaults?: Partial<BaseFormFieldProps> & PlainObject;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming that use of PlainObject here means that you can put any key and TS will accept. But if you specify a key that is on BaseFormFieldProps we will get some validation on it, right?

Is mobile vs. desktop split the thing that's driving this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DefaultHoistProps was effectively an alias for PlainObject. Happy to revert this change, but in the process of reviewing some of this with Lee, we talked about the possibility of removing DefaultHoistProps entirely, so lots to consider here! I'm not entirely sure why this needs to be so generous-- might be desktop vs mobile, will investigate.

export const th = elementFactory('th');
export const thead = elementFactory('thead');
export const tr = elementFactory('tr');
export const ul = elementFactory('ul');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice cleanup!

@@ -38,7 +39,7 @@ export interface TabConfig {
icon?: ReactElement;

/** Tooltip for the Tab in the container's TabSwitcher. */
tooltip?: ReactNode;
tooltip?: JSX.Element | string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is new to me - especially vs. ReactElement - would like to understand more

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was to conform with Blueprint's accepted prop type (ReactNode was too broad)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants