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

Double Props definition when working with TypeScript #22

Open
SoftHai opened this issue Mar 28, 2020 · 3 comments
Open

Double Props definition when working with TypeScript #22

SoftHai opened this issue Mar 28, 2020 · 3 comments
Labels
documentation Improvements or additions to documentation

Comments

@SoftHai
Copy link

SoftHai commented Mar 28, 2020

Hi,

when working with TypeScript Components, it is needed to define the props definition twice:

  • As the TypeScript way (Interface and generic React Component React.Compoennt<PropsType>) for type checking in the code
  • As a PropTypes definitions for being reflected in the Webcodesk UI
import React from 'react';
import PropTypes from 'prop-types';

export interface CompProps {
    text: string;
}


class CompName extends React.Component<CompProps > {

    static propTypes = {

        text: PropTypes.string
      }

    static defaultProps = {
        text: "Hallo World"
    }

    render() {
        return <div>{this.props.text}</div>
    }
}

export default CompName;

It would be nice when for TypeScript compoenents the TypeScript Props definition could be used to show and reflect the definition in the Webcodesk UI. That would make maintenance easier.

@ipselon
Copy link
Contributor

ipselon commented Mar 29, 2020

You are quite right about doubling the efforts when adding types for TS. There are a few reasons for such a situation:

  • As far as TS has only a compile-time type checking, I'd like to keep the run-time testing also. That is, we have to write PropTypes for the propTypes property.
  • Additionally, I'd like to have a single source of truth of the prop types for Webcodesk in different languages (TS or JS).

I have a pattern of the component class that could be useful and satisfies IDE's intellisense:

import React from 'react';
import PropTypes from 'prop-types';

interface PrimaryButtonProps {
  text: string;
  onClick?: () => void;
}

/**
 * Button is generated by Webcodesk. Replace this comment with a valuable description.
 */
class PrimaryButton extends React.Component<PrimaryButtonProps, any> {

  static propTypes: PropTypes.InferProps<PrimaryButtonProps> = {
    /**
     * Label of the button.
     */
    text: PropTypes.string.isRequired,
    /**
     * Triggered when the user clicks on the button
     */
    onClick: PropTypes.func,
  };

  static defaultProps: PrimaryButtonProps = {
    text: 'Button',
  };

  // constructor(props: PrimaryButtonProps) {
  //   super(props);
  // }

  handleButtonClick = (e: React.MouseEvent<HTMLElement>): void => {
    if (e) {
      e.stopPropagation();
      e.preventDefault();
    }
    if (this.props.onClick) {
      this.props.onClick();
    }
  };

  render() {
    return (
        <button onClick={this.handleButtonClick}>{this.props.text}</button>
    );
  }
}

export default PrimaryButton;

@SoftHai
Copy link
Author

SoftHai commented Mar 29, 2020

Hi,

thanks for the explanation. Sounds reasonable.
Just took me a while to write the component in the right way to get this UI Props working. But the issue with the non updating props panel was here more the reason, why it took a while.

Maybe it makes sense to add this example (and the one in the other issue regarding the *.funcs.ts type check stuff) to the User Guide or maybe to the a readme in the TypeScript Base Package repository as an kind of documentation to make it easier to work with typescript and speed up the learning curve. Actual all Examples and documentations are just available in JS.

Feel free to close the issue or keep it open as reminder for extending the documentation, if you like.

@ipselon
Copy link
Contributor

ipselon commented Mar 29, 2020

Maybe it makes sense to add this example

Sure, I'll do that. Thanks.

@ipselon ipselon added the documentation Improvements or additions to documentation label Mar 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants