search

gcanti / tcomb-form

Forms library for react
https://gcanti.github.io/tcomb-form
MIT License
1.16k stars 136 forks source link

Contributions and PR for other css frameworks are welcomed #31

Open gcanti opened 9 years ago

gcanti commented 9 years ago

EDIT:

Supported skins:

FoxxMD commented 9 years ago

:+1: I would love to see more frameworks.

I am potentially moving over an app to material-ui soon, if I do this I will be re-implementing my forms with tcomb and will probably build templates for it.

gcanti commented 9 years ago

It would be great! Let me know, if you put up a repo containing the templates I'll add a link to the README file. Thanks @FoxxMD

mbrookes commented 8 years ago

@FoxxMD - Did you develop a Material-UI template in the end?

FoxxMD commented 8 years ago

@mbrookes No I haven't yet. Current projects have taken longer than I thought. Still planning on doing it though!

Xananax commented 8 years ago

I tend to think it would be beneficial for tcomb-forms to render pure inputs, and decouple bootstrap/semantic/ and other implementations to their own repos.

The doc could still advise the following

npm install --save tcomb-form tcom-form-templates-bootstrap
import t from 'tcomb-form';
t.form.Form.templates = require('tcomb-form-templates-bootstrap');

in order for people to get started as fast as they do now.

The decoupling would allow more versatile implementations, as well as a different versioning. I might want to use tcomb-forms-templates-material, even if it hasn't implemented all the inputs (but has the ones I need), whereas I'd have to wait for it to be complete to be integrated in the main tcomb-forms repo.

Without any templates, the default templates would simply render pure <input>s, leaving to regular classnames the responsibility to style things.

I haven't read the code in details, but it seems to me that templates are already decoupled, so the work would basically be to move them to their own repo, and possibly create a "default" templates file (though the README can arguably warn that the module can't be used without installing templates).

gcanti commented 8 years ago

Hi @Xananax I agree, templates should be decoupled to their own repos.

The semantic templates are there because.. well just because it was an experiment (I don't use it for my work). I should create e separate repo for that (and probably I will). The only exception I'd like to keep is the bootstrap templates: as you said tcomb-form needs a "default" templates file, and I'd choose bootstrap over another template file for 3 reasons:

Let's just say the default template is the bootstrap one.

I haven't read the code in details, but it seems to me that templates are already decoupled

Yep! https://github.com/gcanti/tcomb-form/blob/master/GUIDE.md#changing-the-default-language

Xananax commented 8 years ago

I understand your point; it's true that a plain template is simply never going to be used.

I just have a minor point of contention with the current implementation of the bootstrap template, it's that it pulls in the uvdom dependency (and uvdom-boostrap).
Uvdom is small, so it's not a matter of size, and far from me the idea of criticizing the module (I actually like it), but it bugs me a little to bring in an additional dependency that I'm not going to use at all, and that is doing nothing more than what React is already doing.
It would make sense if the renderer was passed to the templates as a dependency injection (so at some point, I could switch from React to VirtualDom, which indeed I'd really like), but as they are now, I fail to see the point in using UvDom for any user that isn't you (no disrespect intended, I realize you created this library for yourself in the first place and are under no obligation to put up with the petty demands of your users).

Sorry if it seems silly, it might just be a personal pet peeve, but I like to have total control over my modules, I usually prefer modules with few dependencies over modules with many. After all, that stuff is going to be served to the user, and I like to be able to squeeze out each unnecessary bite.

But yeah, I understand it's of minor importance, so consider this more as a remark than a demand.

gcanti commented 8 years ago

It's not silly and I absolutely agree with you. Some months ago uvdom was an nice experiment IMO but now that tcomb-form is tightly coupled with React the only reason why is there are the dozens of hours spent in the implementation and testing (bootstrap extras, horizontal forms, etc..). I know I should rewrite the templates with vanilla React but till now I didn't find the time... or the will! :)

Here's the plan:

p.s. The only pro of uvdom over vanilla React is that, being a POJO, is super hackable :) https://github.com/gcanti/tcomb-form/issues/211#issuecomment-144688445

Xananax commented 8 years ago

Glad to read that!

I'd be happy to contribute. I'm swamped with work currently, but if you take a decision about #254, I can attempt a PR. Redoing the templates would be trickier and I probably would never find the time, but I can try to give that a shot too.

The only pro of uvdom over vanilla React is that, being a POJO, is super hackable

Imho React should've been just using POJOs in the first place. I created a bunch of libraries before React existed, with the same core concepts (but of course, not tested and not usable in prod, just experiments) and I always went with plain objects that got transformed. So you could always transform further before rendering. The PHP Drupal framework works that way (that's where I got my inspiration from). Pure objects with a toString function that is their default template, and then middleware plugins consume the tree in the order they were inserted by the user. I think it's a much simpler architecture.
But oh well, I prefer something that is used by thousands and well maintained, even if I would've preferred different design solutions. Just a lengthy paragraph to say I completely understand the want for something like Uvdom.

gcanti commented 8 years ago

Imho React should've been just using POJOs in the first place

But oh well, I prefer something that is used by thousands and well maintained, even if I would've preferred different design solutions

We are on the same page

gcanti commented 8 years ago

gonna take some time

@Xananax not really, thinking twice maybe there's a way to speed up the process:

Result:

Xananax commented 8 years ago

Alternatively, make tcomb-form return POJOs, and let people plug in their renderer. I wish this could become a trend so people can switch freely between React and other shadowdom libraries. But it's probably not a very good idea as it would really hinder ease of use for the lambda user :(

On Wed, Nov 18, 2015, 13:29 Giulio Canti notifications@github.com wrote:

gonna take some time

@Xananax https://github.com/Xananax not really, thinking twice maybe there's a way to speed up the process:

  • remove the import { compile } from 'uvdom/react'; dependency from components.js
  • add it to the bootstrap templates and make all templates return a ReactElement using compile

Result:

  • the core tcomb-form doesn't depend on uvdom
  • the default templates (bootstrap) return a ReactElement
  • I can migrate the template from uvdom to jsx one at the time (no rush needed)

— Reply to this email directly or view it on GitHub https://github.com/gcanti/tcomb-form/issues/31#issuecomment-157684190.

gcanti commented 8 years ago

Updating. Just released v0.8.0 https://github.com/gcanti/tcomb-form/releases/tag/v0.8.0 No more uvdom, uvdom-bootstrap dependencies. Bootstrap and semantic templates in their own repo.

sibelius commented 7 years ago

is there any guide of how to create a skin ?

I would like to help creating one for (material-ui)[https://github.com/callemall/material-ui]

gcanti commented 7 years ago

@sibelius alas there's not a proper guide (it would be helpful having at least the schema of each locals object passed to the templates). It's not nice but you can inspect how https://github.com/gcanti/tcomb-form-templates-bootstrap is implemented