Custom rule controls

[maniax89]

Adds in the ability to customize the components used for the controls for the and elements in the element.

Can be utilized similar to how the getEditor command worked before:

//create a custom component that has access to the original props
class MyCustomComponent extends React.Component {
  render() {
    return(<div />);
  }
}

//make a controls object
const controls = {
  valueEditor: <MyCustomComponent />
}

//pass it into the QueryBuilder
<QueryBuilder fields={[]} controls={controls} />

Addresses #2

[pavanpodila]

I think we can improve a bit more

[pavanpodila]

Don't think we should have this. How about using the render itself to decide whether to render or not? Simplifies the contract of a custom control

[maniax89]

👍

[pavanpodila]

We should add more explicit check with React.PropTypes.Shape since we know it should have one or more of the following props: {field,operator}Selector or valueEditor

[maniax89]

👍

[pavanpodila]

We could just use React.createElement and pass in the props. Let the custom component decide whether or not to render

[maniax89]

👍

[pavanpodila]

Same logic as above about not having a shouldRender

[maniax89]

Not entirely sure what you mean here - I was hoping to check for a child element and render if it exists, otherwise fallback to the default. I can definitely remove the shouldRender from the ValueEditor but is there a better pattern to achieve the "fallback" effect?

[pavanpodila]

We can pass in the fallback element as a prop. The control can return that of it wants to use the fallback.

[maniax89]

but what if there is no custom control? i.e.

controls = {
  valueEditor: null
}

<QueryBuilder controls={controls} />

There won't be a control to render the fallback, right? maybe a short snippet would help me understand better?

[maniax89]

Or are you saying setup the defaults within the QueryBuilder component and then allow users to override it with props? I like that better actually

[pavanpodila]

Ya, the fallbacks will be part of QueryBuilder. Its only when we invoke the ValueEditor where we pass in the fallback as a prop.

const props = {
      operator, field,
      fallbackControl: (<Input type="text" />)
};

const editor = React.createElement(ValueEditor, props)

The ValueEditor can decide what to do in its render

class MyEditor extends React.Component {
        render() {
            // render the custom editor or use this.props.fallbackControl as the return value
        }
}

HTH.

[pavanpodila]

Also if there is no customControl provided, we use the fallback baked into QueryBuilder

[maniax89]

made a lot of changes to see if it fits better now. Also, do you want me to run the distribution build as well to check in the build artifacts along with this? or does that come as a separate PR?

[maniax89]

not sure if you saw the latest updates - it uses the createElement and has a fallback without having to pass any fallback element through

[pavanpodila]

Little swamped right now. Will take a look later tonight. Might have missed it. Thanks for checking in

Thanks,
Pavan

On Sep 30, 2016, at 11:27 AM, maniax89 [email protected] wrote:

not sure if you saw the latest updates - it uses the createElement and has a fallback without having to pass any fallback element through

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[maniax89]

hi just checking in to see if you had a look yet. no rush, just seeing if there is anything else I could do

[pavanpodila]

Looks good to me overall. Will merge.

[pavanpodila]

I think we also need to improve the code coverage in our unit tests. I was thinking of using Jest. What do you think?

[pavanpodila]

@maniax89 BTW, I think now would be a good time to start a changelog.md ? I definitely want to credit you for your PR. Do you mind creating one and listing the changes/features you introduced?

I'll make a new NPM release once you have it 🍸

[maniax89]

Yes I can start a CHANGELOG.md with a list of feature additions. I guess I will add the tag as well. Since you were OK with the changes I made - I was going to continue doing the same with the buttons in the same fashion so all the components are customizable.

In terms of Jest, I haven't used it before but sounds fine. I think it would be good to get a travis.yml file in here so that the tests run with each PR and then merging is dependent on passing those tests. I think it is as easy as logging into travis https://docs.travis-ci.com/user/getting-started/#Step-one%3A-Sign-in then adding this file to the repo:

.travis.yml

language: node_js
node_js:
  - "0.10"