Add a --prop-types option for component generators to automatically include propType validations about redux-cli HOT 12 OPEN

@xml - did you create a new project using redux new? This creates a new project using react-redux-starter-kit which uses redux-cli but has it's own version of blueprints (see here), which are different to the default blueprints. I think the difference you noticed is due to flow.

Personally I'd recommend setting up a project yourself then adding in redux-cli to that (with redux init) so you know how everything in it works. Or I think if you delete those blueprints within your generated project then redux-cli will use the default ones instead (and you can mostly ignore the flow stuff). Hope this helps.

from redux-cli.

Hi, @SpencerCDixon . Redux-cli is excellent. Thank you.

How does this conversation relate to the fact that: in the examples in README, there is setup to have fairly standard propTypes on the components:

import React, { Component, PropTypes } from 'react';

const propTypes = {
};

class <%= pascalEntityName %> extends Component {
}

<%= pascalEntityName %>.propTypes = propTypes;

But in the blueprints I see in my fresh installation, it's more like:

import React from 'react'

type Props = {}

export class <%= pascalEntityName %> extends React.Component {
  props: Props;
  render () {}
}

This may just be a syntax I'm unfamiliar with as yet, but: where did the propTypes go, and what is that syntax that replaced them, please?

from redux-cli.

@bobwhitelock - I did indeed use redux new. And now that I look at react-redux-starter-kit, I see the blueprints there, and see that the new syntax does indeed come from there. (Which is odd, because Flow is not mentioned anywhere, and I don't see it listed as a dependency...)

I see that redux-cli includes its own blueprint files in the repo, which use the traditional syntax, but I don't seem to have gotten those. I've got the ones from react-redux-starter-kit, including the new ones for layout and view. So, if redux-cli is supposed to be replacing those with its own... it's not happening.

If the blueprints are a feature that only works with redux-cli, and if you already have them here in this repo, why on earth have they duplicated/replaced them in react-redux-starter-kit?

from redux-cli.

Yeah local blueprints will override the very limited ones that come with the CLI. Feel free to modify the blueprints in your projects blueprint to customize the generators to your specific needs. (I.E. remove flow)

from redux-cli.

if we can get #6 working, this should be straightforward to add. The question then becomes what set of code we inject and can we make it possible to customize the code that gets injected.

If we can't, one of my 2.0 goals to provide a mechanism to copy a blueprint into your local directory to make it easier to customize. As well as provide better ways to share blueprints. This allows the user to customize their own blueprints according to their own style and preferences.

from redux-cli.

#110 will address this. And this issue will be closed when it is accepted

from redux-cli.

#110 will certainly make it trivial to pass a --prop-types option to blueprints. What a blueprint chooses to do with it is another matter.

There's some crossover here with blueprint partials. Might we have options partials? And/or core options that are available to all blueprints (e.g. --path) or that blueprints could potentially opt in/out of?

Prop types can/would be rendered differently in different scenarios. E.g. propTypes property on an 'extends React.Component' class vs pure.propTypes definition on a pure/function component declaration.

What could be common to both is the list of props. That in turn could have different levels of specificity.

--prop-types foo bar

...defines props foo & bar (defaulting to PropType.any)

--prop-types foo:string bar:object

...setting both the prop and the PropType

There could also be some crossover with other options, e.g. --props and/or --destructure.

bp generate pure FooBar --prop-types foo:string bar:object --destructure --as div

...generates...

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

const FooBar = ({ foo, bar }) => <div />

FooBar.propTypes = {
  foo: PropTypes.string,
  bar: PropTypes.object
}

from redux-cli.

Perhaps the common functionality we expose is more rudimentary. E.g. #5 would also benefit from similar option parsing functionality

--fields foo bar
--fields foo:text bar:select
--fields foo:Input:text bar:Input:select

I.e. pass field or field:type or field:component:type.

So we could expose an option (array) parsing function that splits values on ':' (or something else) and returns an object with specified keys.

from redux-cli.

Looks like yargs supports array parsing. That should make that easy. Most of the heavy lifting would need to be done by the blueprint, but that's to be expected.

from redux-cli.

#110 has been merged, but there is useful discussion here that has implications beyond the cli part.

So I'm going to leave this open until we have an implementation plan.

from redux-cli.

I think we should implement this as a helper method somewhere. hand it the raw array and have it return a object of trait information that individual blueprints could use and iterate over.

Also what about using a ! as in foo:text! to become PropTypes.string.isRequired

from redux-cli.

yargs array parsing is exactly what I had in mind, it's already being used to pass command aliases to the blueprint blueprint. An array option can also be used as a boolean to e.g.

--prop-types simply adds a placeholder to the generated file so the user can add PropTypes later
--prop-types foo:string bar:int also generates the definitions
--prop-types --dry-run does what you want and sets the dryRun flag rather than passing '--dry-run' as a value to the propTypes array.

I like the ! to .isRequired marker. 👍

I was originally thinking of a very simple split(':') to extract pieces from individual values but that doesn't fit well with !. Easy enough to do with RegEx. I'll think some more about a clean way to hook options, and their parsing, into blueprints

from redux-cli.