How many people use React in Meteor? I do

I plan to try React too, but I’m not sour about alternative of AutoForm for React.
Please help me.

Agree when taking on bigger projects, for first time startup projects generally the size is limited and rewrites of parts tend to happen almost for sure. Anyway, bit off topic :wink:

We use React in our Meteor Projects :slight_smile:

Well, I think it would be a pretty cool thing to make react work with Autoform. Autoform is great, but I wish it was a little more like django’s model/form relationship, where the form extends the model… It’s easier to add attributes and the such.
Autoform is working for me, although I am stuck with it trying to insert a component in the middle of two form inputs with Yogi:MeteorAdmin. the admin panel It gets me like 80% of the way there in use with meteor admin, but I’ve updated it to use the latest datatables, this project got left by the wayside, but I haven’t found anything better yet.

I still believe that MDG needs to sponsor a proper admin tool. I can’t tell you how useful this is for prototyping, I’ve ranted about this before, and people object, but a reactive admin tool is a great feature that separates the project from others, like Ruby /Django

A ReactJS Meteor Admin:

  • Would have auto-paginated scrolling tables, that would subscribe to documents as the user scrolls, no page indicators…
  • Work with Schema and current implementations of autoform but with ReactJS JSX components
  • Would be easy to extend and customize
  • Would handle permissions similar to the way meteor admin does
  • Would be fast

I think the main problem with meteor admin is that it uses iron router, and I have to say, the whole way we subscribe to collections in iron router to getMeteorData is kind of short-sited. Often, I need to call server methods, and publishComposite kind of scares me off a bit, Why can’t meteor method callbacks be reactive automatically? How did we get down this road of using session variables to manage method call callbacks in the router, ick… Why do we not just use a promises for both method calls and subscriptions? We can add as much into our promise as necessary, make sure they are all done before our react component renders.

For instance consider this work flow: I need to subscribe to a collection, then I want to do a custom widget on top of my admin form so I need to also call a server method to complete the task. Right now, getMeteorData does not work together with waitOn, you can use one or the other. A chain of promises. I guess it’s time to move to flow router, since it seems to solve this problem more elegantly.

This is the code that hurts me a little bit to write for iron router:

  @route "winner_invite",
    path: "/winner_invite/:invitationId"
    action: -> @render("addressFormLayout")
    loadingTemplate: 'loading'
    waitOn: ->
      invitationId = @params.invitationId
      Meteor.call( 'getAddress', invitationId,  (error, result) ->
        address = result
        Meteor.call( 'getProfileByInviteId', invitationId,  (error, result) ->
          Session.set('profile', result) if result
          Session.set('addressData', address) if address
         )
       )
      return [ -> Session.get('addressData') ]

I have just decided to use React with Meteor for a new project after evaluating a role it yourself full node based stack using React, Redux, and Express. And this morning after seeing Meteor 1.3 beta I’m even more convinced that React with Meteor is the way to go.