Actually, I just recently slowly refactored a 1 year old project from blaze to react.
You start from the bottom up. You replace the bottom of the components tree and and once all the components that shares the same parent are converted, you convert the parent. You traverse like these until you replace the top most component.
Meteor already offers {{> React Component}} so this is very simple to do. There is no react wrapping meteor because you are replacing all children before the parent.
Thanks! iāll use this as an example and spike something out this weekend. Iām currently using TabularTables in a React app and thatās also using the configs for the client/server and collections, etcā¦ However, that might be too simple of an example (though more involved that loginButtons). I forget exactly what I did but you have to pass in the opts into Blaze a different way and also when passing in a function it has to handle it a bit differently such as:
{{#someHelper id="foo" name=somFunc }}
If iām remembering correctly Blaze implicitly calls the function where as React does not, though that would be easier for MDG to handle I think I had to work around it somehow in the adapter.
ps. @SkinnyGeek1010 check out what I just added to my previous post.
ā¦so you opted for many React islands? Howād that work out for you?
The only thing I see wrong with that is the absolute #1 reason to move to React is to get access to React Nativeāthatās a long time before you get access to React Native. I guess it would be that way either wayāsince Blaze likely gotta be all gone by the time you get to React Native land.
TabularTables is another perfect example, but for a different reason: itās a package that does work on both the view layer and on the server. I.e. stuff youāre not going to get from React addons. It signifies why itās so important we make this as seamless as possible: it will harm our access not just to the view, but solutions/abstractions weāve been using on the server as well. Thereās a lot of tightly coupled Meteor + Blaze packages. And we get a lot of power and automation out of that coupling. Anyway, you get the ideaā¦
I mean I dont literally start refactoring small thingsā¦ You can replace at least half part of a page really easily. Itās almost 1 to 1 mapping from blaze to react.
My app has been fully converted, the factoring peroid was like 2 months, but i was also making new pages using react too, if i was just refactoring old old it would have taken me even less time.
Reactive Native is definitely a big factor for leaning react. I have heard from multiple experience IOS devs telling me react native is just about everything better than developing in Swift/Objective C.
The thing i also absolutely hated about old templating system is the constant switching between two files of html and js, and they are āmagicallyā connected, you end up bug fixing for hours to realize you spelt something wrong. If i spelled anything wrong i will know where exactly the error traces to in react. Even better when using webpack imports. But thatās just me tho.
yea, to me iām super excited to get to React Nativeāif I can finally get the chance. Gotta make this Blaze transpiler (among other things) firstāthatās the approach im takin at least.
Itās gonna be exciting in React, when you donāt have to do getMeteorData and just calling component methods tracks its reactive dependenciesā¦
Cool, maybe iāll add that to my demo app as well. I only have about an hour to work on it but iād like to ship something to GitHub that has an example. If there are any others you can think of I can throw those in too.
those are literally the main ones. Funny thingāafter all this hubbub, I dont even use that many client side packages lol. Im an asshole ā¦throw in a modal bootstrap one, naxio:flash + a charting library like C3 (peernohell:c3) and call it a day.
Haha. I personally try to stay away from the packages that do 5 things and I usually opt for one that goes along the lines of āthe unix wayāā¦ but hey sometimes a one liner to install a reactive table is just what the DR ordered.
Wellā¦ unless the client wants it changed. Then youāre pulling your hair out
Tabular is pretty feature packed. I got a few client projects that are essentially page after page of these tables, and the client is ecstatic. You just gotta manage expectations, know a packageās limitations, and like you said put it to use when its exactly what the Dr. ordered. ā¦Perhaps only take clients that require Tabular lol.
Haha. Yea it started asā¦ nice! this is great. Then a change here. another change there. Pretty soon iām monkey patching to get new functionality. Oh well. Gotta love agile
@SkinnyGeek1010 I got some goodies just for your eyes. I need someone to take a look at it before I launch it:
all is prepared with super automated examples, etc. i.e. just run the commands in the readmes. Itās the āDeep Tracker integrationā @gschmidt and @evanyou alluded to the other day. Basically itās āmethod levelā reactivity, and no more need to āfreezeā the reactivity in getMeteorData. Itās a simple mixin called TrackerReact. It basically was intended to be part of @timbrandin 's Sideburns, but I figured since rendering all of Blaze 1 is taking longer to get right, might as well start releasing these things for Meteor+React today.
Youāre a bigger React user than I am. Try to break it!
The only issue I could find is if u accidentally run a reactive method in another. Iām gonna add code to test for that and prevent using a second autorun.
Iām curious thoughādoes it stay consistent with complex state changes and trickling down lots of props to a large tree of componentsā¦
I think I had to work around it somehow in the adapter.
