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

Support for SimpleSchema@2.0.0 #99

Closed
radekmie opened this issue Aug 31, 2016 · 13 comments
Closed

Support for SimpleSchema@2.0.0 #99

radekmie opened this issue Aug 31, 2016 · 13 comments
Assignees
Labels
Type: Feature New features and feature requests

Comments

@radekmie
Copy link
Contributor

Release note.

@radekmie radekmie added the Type: Feature New features and feature requests label Aug 31, 2016
@radekmie radekmie self-assigned this Aug 31, 2016
@serkandurusoy
Copy link
Contributor

This is a breaking change, though! What are your thoughts on backwards compatibility?

@radekmie
Copy link
Contributor Author

radekmie commented Aug 31, 2016

I want to support both at once - simply create another birdge like SimpleSchema2Bridge.

@radekmie
Copy link
Contributor Author

radekmie commented Sep 2, 2016

Well, there's a problem: SimpleSchema.oneOf.

@macrozone
Copy link
Contributor

would love to use simpleSchema 2. Then, we could finally use schema-based-forms in non-meteor-environements like storybook <3<3<3

I also spotted some breaking changes for my usage, but it should be fairly straight-forward.

@radekmie
Copy link
Contributor Author

OK, I've started to implement this and there's one big issue with the new version internals - due to oneOf, every field is treated as an array. To make it possible in any way, then we could either always get the first one or configure it somehow.

@radekmie
Copy link
Contributor Author

Well, I think I've got a solution.

import SimpleSchema from 'simpl-schema';

const schema = new SimpleSchema({
    // Only one type = no problem
    fieldA: String, // String

    // Only one type = no problem
    fieldB: { // String
        type: String
    },

    // Few types = first type
    fieldC: { // String
        type: SimpleSchema.oneOf(String, Number)
    },

    // Few types, one with type = selected one
    fieldD: { // Number
        type: SimpleSchema.oneOf(String, {
            type: Number,
            uniformsType: true
        })
    },

    // Few types, few with type = first selected one
    fieldE: { // String
        type: SimpleSchema.oneOf({
            type: String, 
            uniformsType: true
        }, {
            type: Number,
            uniformsType: true
        })
    }
});

Problem: two types in schema - how to render one form with type 1 and another form with type 2?

What do you think?

@macrozone
Copy link
Contributor

I think i would not hook into the oneOf-function.

If you get this schema, you can't guess which field to render. So the developer would need to specify the field either by using an explicit field in the or by specifying a component in the schema:

import SimpleSchema from 'simpl-schema';

const schema = new SimpleSchema({

    fieldC: { 
        type: SimpleSchema.oneOf(String, Number),
        uniforms: {
           component: TextField, 
        }
    },
});

If nothing is specified, i would just use the first type. I think that this is an edge-case anyway.

@radekmie
Copy link
Contributor Author

But I can't guess type from the field. Consider this example:

import SimpleSchema from 'simpl-schema';

const schema = new SimpleSchema({
    fieldA: { 
        type: SimpleSchema.oneOf(String, [String]),
        uniforms: {
           component: CustomField
        }
    },
    fieldB: { 
        type: SimpleSchema.oneOf(
            {type: String, min: 10},
            {type: String, max: 10}
        ),
        uniforms: {
           component: TextField
        }
    }
});

Which one should we render now?

@macrozone
Copy link
Contributor

macrozone commented Sep 16, 2016

In the first case, you render CustomField (fieldA) and in the second case a TextField with property min: 10. (fieldB, this definition makes little sense anyway).

Or maybe i don't understand the problem?

Edit: SimpleSchema.oneOf just say that any of this definitions are valid types. So the rendered field has just to fullfill this validation. If e.g. String or Number are both fine, then both a TextField and a NumberField can fullfill this validation.

I hardly see a usecase for this. Maybe if you want to switch conditionally between two valid definitions and render the best form-element for that definition. But that would need to be specified in the form.

@radekmie
Copy link
Contributor Author

radekmie commented Sep 16, 2016

Yeah, of course fieldA will render CustomField, but every field receive it's type (and other props).

Maybe this will clarify:

{
    userId: {
        type: SimpleSchema.oneOf({
            type: String,
            regEx: /^.{16}$/
        }, {
            type: String,
            allowedValues: [
                'admin',
                'tester',
                'guest'
            ]
        })
    }
}

No matter, which field I'll render - which props should I provide?

Edit: Of course, those are quite esoteric schemas, but possible ones.

@radekmie
Copy link
Contributor Author

radekmie commented Sep 27, 2016

Done! I've implemented it in 1.1.0 - go and check it out. Right now, there's no support for SimpleSchema.oneOf(...) with multiple types - only first one is used.


EDIT: It will work in 1.1.1 - I forgot to export it in 1.1.0, sorry.

@logankoester
Copy link
Contributor

Awesome, thank you! 😍

@macrozone
Copy link
Contributor

Love you guy <3

Logan Koester notifications@github.com schrieb am Mi., 28. Sep. 2016,
08:44:

Awesome, thank you! 😍


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#99 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB4YgWVqDqqN4jRU3W4Syzg53R4Cxi96ks5qugzegaJpZM4JyEQE
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature New features and feature requests
Projects
Archived in project
Development

No branches or pull requests

4 participants