I’ve delivered several apps, few of which were line of business apps consisting mainly of forms and tables. And by the looks of it, most of my upcoming projects will be as such.
Autoform’s quickform usually gets to the rescue, but once I need customizations especially regarding form layout I have to expand that one-liner into autoform/quickfield/inputfield definitions which often end up quite complicated and verbose.
I really really miss the declarative approaches that Java’s facelets and JSF component libraries had.
Now that there’s the react/blaze discussions going on, and I’m dismissing Angular, I guess I’ll need to bite the bullet and go full on React.
The thing is, I’m experienced with Blaze and all the blaze packages out there, I know their quirks, inner workings, their developers, the kind of code quality and support I can expect, if the author is open to constructive critisism and pull requests etc.
I have nowhere near such familiarity with the React ecosystem. So I’m asking you guys to point me in some kind of direction.
What I’m basically shopping for is:
Tables that easily:
handle large datasets (millions of records)
filter/sort (server side) on such datasets
play nice with reywood:publish-composite
display cells with custom template, but filter/sort on non-transformed data (ie, display a date as “January 10, 1987” but sort as the underlying date data)
Accept global styling and themeing, not directly bound to bootstrap styles
Forms that easily
Preferably take its layout definition from a configuration or schema
At least provide some preferably declarative, not-too-verbose way to design a form layout
Help in validation and displaying errors etc depending on state
Support some kind of internationalization (label translation, date and number formatting)
Provide an API that allows rogrammatic manipulation of the inputs and controls
Support for master detail type scenarios either by adding/removing lines that get stored in an array, or better yet sub-forms that persist to a foreign collection (as in an invoice and the line items of that invoice) if desired
Support passing form content to a method, possibly providing a hook/callback system around form and control events
Support persisting form directly onto a collection might be a plus for certain simple use-cases as well
Accept global styling and themeing, not directly bound to bootstrap styles
Edit:
As much as I like manuel:veiw-model, I’m - sadly - ruling that out due to React taking over Meteor UI.
I tried and did not like webix and kendo since the final code looks like a mess. I really want to be able to gaze over the code and kind of be able to picture what it would look like rendered
Yep, it is kind of a drag but what needs to be done needs to be done.
Anyway, I think the tables situation is not that bad. https://react.parts/web?search=table although I have my doubts about how server side sort/filter would work with meteor’s pub/sub mechanisms.
On the other hand, the forms story looks very immature. There seems to be a new forms solution popping up every day and many devs still roll their own.
I guess the main problem is, react is a pure front end framework while I was very used to how blaze did not care much about the fornt/back end difference and everything kind of fit in.
For example, with forms, none of the form-schema solutions can be reused for backend schema validation for inserting/updating to the collections. If one were to do method/insert validation and form validation, they need to be separate pieces of code which is very unlike meteor and very unlike the optimistic ui story I’ve been used to.
UC Santa Cruz is in the same boat, as far as forms go.
For the past six months, I’ve been rewriting their Clinical Forms application, and learning the entire autoforms package. Can’t say that I’m thrilled with the state of things, but we have a plan for managing the migration to React. Long story short, I just finished writing around 1500 acceptance tests for a dozen questionnaires built using Autoforms, and am ready to finally fork the autoforms package into the Clinical Meteor track. Since the acceptance tests aren’t tied to implementation, we can experiment with swapping out the underlying form generation library.
Our reference app currently includes a form builder. However, it is implemented with a Card UI design philosophy. (So, Minority Report interface or bust, I suppose.)
I’ve been having some initial success with handsontable, although it wants to manage its own DOM, so I don’t know how much of a long-term solution it is.
@awatson1978 thanks for chiming in. You sound like you are still going to be using autoform one way or another, am I right? So what’s your plan on the React transition? Will you simply render the autoform-generated blaze template into the react component using one of the bridging packages out there?
@aadams checkboxes and radio buttons are kind of tricky and there are so many things that can go wrong. Especially if the underlying data model is based on booleans. But if you are using autoform, it does its best to keep it sane. Also, the community is pretty quick to come up with solutions once you post a question on the issue tracker.
@npareek I’ve “investigated” (not a hands-on evaluation) them both, tcomb uses a proprietary schema definition and winterfell looks really hard to reason about in terms of layout.
Actually, Eric worked on the CRF application prior to me, so UCSC has been supporting autoforms for a year or two now, in one way or another. I don’t know this for a fact, but it seems that Eric’s declaring autoforms complete happened about the same time he left the CRF project for other opportunities.
So, like I said… we’ve been writing acceptance tests in preparation for an underlying implementation change; and are keeping a close eye on Sideburns/ReactBlaze/etc. The exact implementation doesn’t matter too much to us, just so long as it conforms to the Spacebars APIs that was basically specified at Meteor 1.0. Once we make that migration, I suspect we’ll look at mapping the autoforms functions to the underlying React functions, and removing the templating interface.
As for radios/checkboxes/selects, we’ve gotten most all of that under QA with our Nightwatch scripts using css selectors. I used to be kind of uncomfortable with them, but am becoming much more confident with the QA tests. What’s giving us headaches now are nested objects.
It is very reassuring to know that there are so many tests running against autoform! Do you consider PR’ing them to the official autoform repo?
Nested objects have their quirks, especially with their validation, but as long as they are not arrays, they can be tamed. I can’t say the same or arrays, especially with [Object] which contain boolean-radio's. I’ve had so many bug reports from clients reporting that they lose their state as soon as new lines are added to the array. And it is not a consistent bug so a reproduction is really hard to produce for an official bug report aaah
More likely, we’re going to create a package that has a dozen form schema definitions, and a dozen acceptance test commands (which each get their own file, as per Nightwatch design). The new testing MVD includes a meteor test command which exposes test assets after build, which means that Nightwatch will be able to scan and pick them up.
Put another way, instead of internal unit tests, we want to create a package of a dozen forms that export testing helper functions that say ‘this form should look like this, and have these elements after its rendered’.
Unfortunately, we’re dealing with Arrays also… :sigh:
instead of internal unit tests, we want to create a package of a dozen forms that export testing helper functions that say ‘this form should look like this, and have these elements after its rendered’.
Even better! Unit tests would probably not work for every app anyway, so a battle-tested examples of form definitions and accompanying test would be pretty helpful.
Unfortunately, we’re dealing with Arrays also… :sigh:
It’s still very preliminary, and I have a lot of plans for it. I still have to add textarea, select, etc., as well as adding callbacks to input fields for all kinds of custom functionality (verifying data in the db). Still, it’s good enough to the point where I’m using it and adding stuff on when I have the time.
I probably won’t make it generate fully complete HTML forms like autoform does. I want to keep it in pieces to give more control to the developer.
@serkandurusoy: OHHHHH NO… why are all you good people leaving Blaze?
I mean: Why switch to react when all we want is to program a business app. Is ReactNative really such an important selling point over the great Blaze? In other words: doesn’t Blaze and the aldeed:stuff combined with a responsive css framwork (making it mobile-compatible) do a great job - even on mobile?
@ffxsam thanks for sharing that. The thing is, this is kind of my point. React is not built for meteor, therefore as soon as I bring in react, I kind of lose a lot of the goodness that meteor offers. Starting with code duplication. Besides, what good is react if I can’t actually use the react ecosystem seamlessly? In other words, why should I then use Meteor if I go React?
Anyway, I’m still searching for the right toolsets and really don’t want to dive in blindly, just hoping for the better.
@thebarty thank you for the compliment, I guess and well, I’m not going anywhere, yet! @tmeasday shared an interesting opinion over at this thread.
My problem is, I need the stability since these line of business apps are developed for businesses who see their software investments as long term assets and don’t want to switch technologies unless there is some really serious business value. Therefore I need the peace of mind that what I deliver now will continue to get support, bugfixes and some enhancements, all the while allowing me to do general meteor update on the code.
Therefore, if react is what’s going to get me that, I have to go that route. But if blaze is to satisfy those conditions, then I’m undoubtedly all for blaze!
And finally, if I’m going to go with React, I need to pick the brains of the more experienced react developers to make sure I’m betting on the best possible component libraries that fit my requirements.
I’m not quite sure what you mean. React is just a layer over Meteor, in a similar way that Blaze is. I’ll grant you that Blaze is much more tightly adapted to Meteor’s infrastructure with regards to reactivity, but I’m curious about what kinds of “goodness” you feel you’re missing with Meteor+React.
what kinds of “goodness” you feel you’re missing with Meteor+React.
Blaze is obviously built from ground up to be part of meteor’s reactive lifecycle. React offers it - officially - with a mixin, still lacking the ability to sprinkle reactive sources around. No automatic starting and cleaning of computations.
I know you and a few other brilliant developers are working to solve that problem, but I cannot rely on that.
Enterprises need the peace of mind of having official integrations. As far as official goes, react still feels like a square in a round hole.
Let’s see if we can solve that problem there.
