TypeScript definition d.ts file? about react-masonry-component HOT 16 CLOSED

@emzero I've updated the typings to import React directly. Can you please let me know if this works for you?

This was a quick "fix" based on an hour of reading, not sure if it's going to work.

Either way, you've motivated me to start taking TypeScript a bit more seriously.

[email protected]

from react-masonry-component.

@emzero Yeah no issues with that

from react-masonry-component.

@emzero do you feel like contributing one? 😛

from react-masonry-component.

@afram I'm actually pretty new to TypeScript and definitions so I did my bare minimum to make it work.

Here's what I got. I don't think a full PR is worth it, so here you go. Anyone is welcome to improve it.

declare module "react-masonry-component" {
  import React = __React;

  interface MasonryPropTypes {
    disableImagesLoaded: boolean;
    options: Object;
    className: string;
    elementType: string
  }

  export var Masonry: React.Component<MasonryPropTypes, void>;
}

from react-masonry-component.

@emzero No worries.

I don't use TypeScript, please let me know how this beta version works for you. If it's all good I can release the next version.

npm i [email protected] -S

from react-masonry-component.

So, I am actually curious -- why TypeScript over React PropTypes?

MasonryComponent.propTypes = {
  disableImagesLoaded: PropTypes.bool,
  onImagesLoaded:      PropTypes.func,
  options:             PropTypes.object
};

See my fork for example:

https://github.com/wjramos/react-masonry-component/blob/masonry/components/MasonryComponent.js

from react-masonry-component.

@wjramos With TypeScript there's no need to use React PropTypes since a strongly-typed component using an interface to describe the props provides the same type checking at compile time.

Related

from react-masonry-component.

@afram That doesn't work because it depends on React typings being installed as a global module and might not be always the case. I'm also getting another error from Typescript.

TypeScript 2.0 is about to be released and it will drastically improve the way d.ts files are distributed for npm packages. So I would suggest that we just wait for it to include a proper d.ts file.

In the meantime, you could include a section in the readme saying something like...

If you are using TypeScript, include the following code in your custom definition file.

declare module "react-masonry-component" {
  import React = __React;

  interface MasonryPropTypes {
    disableImagesLoaded: boolean;
    options: Object;
    className: string;
    elementType: string
  }

  export var Masonry: React.Component<MasonryPropTypes, void>;
}

from react-masonry-component.

@emzero wouldn't it be adding an otherwise unnecessary dependency?

from react-masonry-component.

@wjramos What do you mean?

EDIT: I think I understand what you're saying now.

I opened this issue to ask the author to include TypeScript definitions. This does not mean the library is going to depend on TypeScript. It's just a file that's needed if the library is going to be used in a TypeScript environment.

The original Javascript can still make use of PropTypes while the Typescript definition file uses an interface to define the props.

from react-masonry-component.

The TypeScript compiler is complaining.

ERROR in node_modules\react-masonry-component\typings.d.ts (5,15):
error TS2665: Module augmentation cannot introduce new names in the top level scope.

ERROR in node_modules\react-masonry-component\typings.d.ts (14,16):
error TS2665: Module augmentation cannot introduce new names in the top level scope.

I actually have no idea how to make use of another external lib's typings. I've posted a question on SO but no answers yet.

As I said, TypeScript 2.0 will use npm to manage typings so it should provide better dependency management.

from react-masonry-component.

@emzero I think I may have found a possible solution, can you please try this version? Appreciate your help in getting it out there :-)

[email protected]

from react-masonry-component.

@afram

I'm using typescript@next which is the 2.0 preview version for the next TS version that's just around the corner.
The following declaration file works great with this version. I wouldn't really bother to make it work with 1.8 today.

import { Component } from "react";

declare module "react-masonry-component" {

  export interface MasonryOptions {
    columnWidth?: number;
    itemSelector?: string;
    gutter?: number;
    percentPosition?: boolean;
    stamp?: string;
    fitWidth?: boolean;
    originLeft?: boolean;
    originTop?: boolean;
    containerStyle?: Object;
    transitionDuration?: string;
    resize?: boolean;
    initLayout?: boolean;
  }

  interface MasonryPropTypes {
    disableImagesLoaded?: boolean;
    updateOnEachImageLoad?: boolean;
    onImagesLoaded?: (instance: any) => void;
    options?: MasonryOptions;
    className?: string;
    elementType?: string;
  }

  export default class Masonry extends Component<MasonryPropTypes, void> { }
}

I've also added an interface for the options.

from react-masonry-component.

Great thanks, this has been merged into v4.2.0

from react-masonry-component.

@afram Could you add a line to the interface MasonryPropTypes so we can add styles to it?

interface MasonryPropTypes {
    disableImagesLoaded?: boolean;
    updateOnEachImageLoad?: boolean;
    onImagesLoaded?: (instance: any) => void;
    options?: MasonryOptions;
    className?: string;
    elementType?: string;
    style?: Object: // ADDED
  }

from react-masonry-component.

done v4.2.1

from react-masonry-component.