#299 Switching to React

[Anonymous]

Originally created by: mquandalle

Wekan currently use Blaze as its view layer, a library written by Meteor Development Group that aims to be easy to use for developers. I've been considering replacing Blaze by React for a few months now, and except the migration cost I can see a lot of advantages in doing so:

• Have a clean component API (I currently use blaze-component, which makes things less worse than “vanilla”-blaze and will facilitate the switch to react);
• Embrace the React eco-system which is very prolific in great tools, library, and components. I'm especially interested in react-dnd (great demo) because I already spent too much time fighting with jquery-ui, sortable, and others;
• Functional programming, I'm especially interested in composition possibility for potential plugins made by the community;
• Attract React developers by being a great example of an open-source React application;
• In the future: React native, for native mobile applications (see [#480]);
• In the future: GraphQL and Relay integration for data fetching, as an improvement to our current DDP subscription model.

Despite the (upcoming) official React support by MDG, Meteor build system still misses a lot of requirements to facilitate this transition (imports/exports, easy npm/browserify usage, redux-like hot reloading, etc.). I'll probably need to investigate community solutions such as meteor-react-pack or meteor-webpack-react-kickstart.

We will probably need to run both Blaze and React components at the same time during the transition, which seems to work well with a few helpers functions. Also our templates are currently written in Jade, but the React community tend to prefer JSX, which mean that we will probably want to rewrite our Jade templates in JSX.

[Anonymous]

Originally posted by: shekar73

@mquandalle ...The reasoning seems solid and with the kind of muscle Facebook has, embracing react ecosystem is the way to go to make it future proof, as they seem to be controlling the current popular ideas in web/mobile development and also increases the project's exposure to other React developers (as you mentioned). However, based on my understanding, most of the packages in the meteor universe are closely tied to Blaze and I was wondering how is the impact going to be when using React?.

[Anonymous]

Originally posted by: mquandalle

@nata-g Actually we don’t use a lot of packages that are tightly coupled with Blaze, and for those who are (eg templates:tabs) there exists better alternatives in the React ecosystem.

@AdamBrodzinski you seem to have a lot of experience with React integration in Meteor, I don’t know if you are familiar with Wekan but I'm curious if you have some thoughts to share about migrating this kind of application to React (all the current blaze code is here, .jade and .js files weight about 4K LOC).

[Anonymous]

Originally posted by: mquandalle

Yay! Facebook just launched React Native for Android. As a linux user I was frustrated because I couldn't play with React Native for iOS, now it become possible. Let’s try to build a native Wekan app!

[Anonymous]

Originally posted by: shekar73

👍 👍

[Anonymous]

Originally posted by: AdamBrodzinski

@mquandalle Yep! I've migrated 3 apps so far. The easiest way is to start at the 'leafs' and work your way up the tree. The easiest way to render those is to use a blaze helper but you could also just use the onRendered callback to manually render a React node into a div.

You can pass the data that Meteor is getting into the props param of the rendered method and that will give the component the data it needs. Eventually you'll get to a point where React needs to fetch data (like components/activities) and the best way to do that is to make 2 components.. ActivitiesContainer which is only concerned about getting data and then Activities (normally) just gets props. This tends to separate concerns and makes it easier to debug.

Eventually you'll work your way back up the tree and then can attach the top nodes to a router (if wekan has one).

I would recommend this video for refactoring: https://www.youtube.com/watch?v=BF58ZJ1ZQxY

Cheers! 🍻

[Anonymous]

Originally posted by: bastianwegge

Hey, we're using wekan and it's awesome!
I'd like to take part and help out with some hours. Do you have a board or any specific planning for this?

[Anonymous]

Originally posted by: mquandalle

Hi @bastianwegge, sorry I missed your message. No there is no specific planning for the migration. I feel like Meteor integration with React isn’t mature enough unless we also switch the build system (for instance with https://forums.meteor.com/t/webpack-compiler-inside-meteor-es6-modules-hot-reload-and-code-splitting/11264). I also don’t like the Meteor mixin too much and would prefer to use React stateless functional components (new in React 0.14) and have some sort of wrapper (Higher-order component) that exposes the Meteor data similarly to what Relay does.

Until this eco-system matures a bit I don’t feel super comfortable to engage this transition, but I'm confident the Meteor community will find great solutions in the following weeks. Bastian, do you have some experience with these topics?

[Anonymous]

Originally posted by: AdamBrodzinski

@mquandalle you could wrap the meteor mixin into a higher order component that has a similar API to Redux but uses the mixin to sideload for ease of use. This also creates a facade that would allow you to swap out the mixin if needed. I started tinkering with something like this but moved on to using just Redux once I ran out of time:

let Post = function Post(props) {
  return (
    <div>
      <div className="title">{props.title}</div>
      <div className="desc">{props.desc}</div>
    </div>
  )
}


let Posts = function Posts(props) {
  return (
    <div>
      { props.posts.map(doc => {
         return <Post ...doc />
      }) }
    </div>
  )
}
Posts = fetchMeteorData(Posts, {
  subscribeTo: 'allPosts',
  fields: {posts: {desc: 1, title: 1}}, // passed into subscribe
  mapToProps: () => {
    let docs = db.posts.find({}, {sort: {title: -1}});
    return {
      posts: docs,
    }
  }
})

[Anonymous]

Originally posted by: shekar73

@mquandalle check this: https://forums.meteor.com/t/next-steps-on-blaze-and-the-view-layer/13561

There seems lot of discussion in regards to using React in Blaze 2 (either as templates on top or pure jsx). My guess is MDG is going to integrate React in Blaze ASAP so that they can use Galaxy to host react based apps? Wondering about your thoughts on this issue with reference to Wekan? Do you think we should start thinking of migrating as well ?

[Anonymous]

Originally posted by: shekar73

@mquandalle I guess on reading it more clearly, MDG is replacing blaze with React and adding template support on top of React and some migration layer for an upgrade path. This would change the whole client side development of meteor app. Interesting!!! Thoughts????

[Anonymous]

Originally posted by: floatinghotpot

@mquandalle After implemented the features of email inviting, mobile web and notification, building a native Wekan app might be the most attractive idea. Will follow up this topic, and see if I can contribute a cent or not.

[Anonymous]

Originally posted by: floatinghotpot

Here I see an experimental demo, FYI:
https://github.com/hharnisc/react-native-meteor-websocket-polyfill

[Anonymous]

Originally posted by: mquandalle

@floatinghotpot Your level of enthusiasm is contagious! I would be delighted if you get to contribute to a native Wekan application. I played with React Native back when Facebook released the Android support, it was a bit difficult to set up on my Linux computer but after I got it up and running the developing experience was exceptional! I really think this is the best way for us to write a native application in 2016.

To keep things organized let’s talk about React Native apps in [#480] (which would probably start on a separate repository based on one of the react native starting kit), and keep this thread about the transition to React for the web client.

[Anonymous]

Originally posted by: mquandalle

I also want to share that I’m super excited about @arunoda’s Mantra (early example here) and as we migrate to React I’ll try to stick with as much Mantra principles as possible.

[Anonymous]

Originally posted by: mquandalle

Just want to add yet another important argument in favor of the soon to come migration to React, and that is the possibility to compose UI components. That will be very valuable for our desired plugin system. I wrote about that on the forum.

[Anonymous]

Originally posted by: Asara

Just curious if this is still in planned. 👍

[Anonymous]

Originally posted by: nchauvat

Hi. As a user of Wekan, I would be interested in a move towards React. Do you know about https://github.com/bigardone/phoenix-trello ? Maybe some cross-pollination could bootstrap the transition?

[Anonymous]

Originally posted by: mquandalle

One of the non-trivial part of the Blaze-to-React transition is the card drag and drop feature. From looking at their respective code and documentation, React Dnd has a better design and API than Jquery UI sortable. However I’ve yet to see a Wekan-like kanban written with it and there always were some quirks in the demos I’ve seen.

Does anyone know a good demo of card + column ordering using React Dnd?

[Anonymous]

Originally posted by: nchauvat

http://blog.tryolabs.com/2015/04/30/building-a-kanban-app-in-react/ maybe ?

[Anonymous]

Originally posted by: nata-jimi-shekar73

@mquandalle how about apollo stack update or is it too soon. I was recently reading the docs at http://docs.apollostack.com/ and going over the apollo client (for which you are the contributor) and was wondering wekan might be suited for early testing of apollo + Mantra, now that there is little less confusion in the meteor world. My 2 cents.....

[Anonymous]

Originally posted by: mquandalle

@nata-g Yes, that's actually the idea. I plan to write on the stack I plan to use for the Wekan rewrite.

[Anonymous]

Originally posted by: nata-jimi-shekar73

@mquandalle that would be awesome . Let us know the stack and high level design of Wekan rewrite. May be I can be active contributor this time....

[Anonymous]

Originally posted by: nata-jimi-shekar73

BTW @mquandalle just curious to know if have you decided which approach you plan to use for rewrite - One-on-One mapping of the existing functionality or something that is being discussed here https://discuss.wekan.io/t/abtract-lists-into-a-generalized-task-meta-data/121 ?

[Anonymous]

Originally posted by: mquandalle

The underlined data model will be the one described in the above topic. However with the default set of modules installed the UX will be similar to what we currently have.

[Anonymous]

Originally posted by: nata-jimi-shekar73

@mquandalle Sounds good. You know I was just reading the discourse topic again after a long break. Initially I was little opposed to the idea but now I am seeing the point. I can see the benefit of the new data model and how it can be useful. Now I am looking forward to playing with the app using the new data model 😄