如何看待 React-to-Vue 工具?

03-05

今天看到款神級工具，可以把 React 組件轉為 Vue 組件，據說還支持 TypeScript 語法解析，可以讓組件的復用不僅僅局限在一個框架裡面，終於可以跳著寫代碼了。
貌似沒啥實際意義啊，大家怎麼看？
現在公司一般的現狀是怎麼樣的？會有兩種框架並存的或者框架轉換的需求么？
原文地址：前端神器：一行命令，React 組件轉 Vue 組件！

簡單看了下代碼，談一談我的理解：

react-to-vue，這一聽就是大多數人不願去碰的麻煩事，裡面要堆大量的邏輯，考慮庫的各種特性(維護更是個麻煩事)，如果我們把AST的生成解析用babylon、Babel等第三方庫做了的話(實際上作者也是這麼做的)，我認為剩下的主要是寫邏輯，處理各種特殊情況了。

這個工具我認為在工程上有一定挑戰性，但是難度是線性的(不會特別難，通過自己的學習和不斷的時間堆疊，不少js開發者都能造個差不多)，不過作者願意去花時間搞這個，至少可以證明是熱愛技術並且基礎不錯的。

但是有一個弊端在於，這個工具的後續更新，是要看react和vue的API和寫法的變化的，如果自己持續的去維護，容易被react/vue牽著鼻子走，難有自己的核心體系(因此我覺得大可能是維護不下去)

至於使用，在項目初期拿一些簡單的react、vue組件轉轉也許能提高一些效率，如果組件本身比較複雜，我覺得還是不用挖坑了。

寫了個工具，別罵成狗血了，心塞。。。。

個人認為使用場景：

1. 你如果想開源好的組件，那可以先寫react，再用react-to-vue轉成vue，這樣你寫的組件變成了跨框架的組件，為絕大部分人服務

2. 如果是用vue在開發項目，但是有個組件不想自己開發，但是有現成好的react組件，那可以把它轉成vue，那就拿來主義了，方便啊

3. 如果公司的有些部門想要從react轉vue，進行重構一下，那可以對基本的react組件進行轉化，大大提高了重構效率

之前參加VueConf，該工具的作者作為嘉賓分享了他的輪子：一款對標VsCode的編輯器，這麼快又開發了這麼一款概念溜的飛起的輪子。很佩服作為開發者的能力，我等碼農難以望其項背。

同時想吐槽下貴司完全沒有需求調研階段么。。。。。。

更新

忘記了，微信小程序和支付寶小程序大腰哥已經搞出來了，基於AST來轉換微信和支付寶小程序

實話，我們公司沒有這種需求。不過作為作者 @王駱菲（人稱腰哥，不解釋）的同事，我必須說兩句。

首先，駱菲他本人一開始是想做微信小程序和支付寶小程序的互轉，但最終產出卻是 React 轉 Vue。

駱菲在辦公室里喊出這個想法的時候，我投去了鄙夷的眼光，喊道，一能不能實現，React 和 Vue 有那麼大的差異；二有多少場景有這種需求。

結果他默默做了幾個月，終於產出了，據說可以轉我們公司React UI 90% 的組件。發現我的鄙夷的眼光有了效果，大兄弟終於還是做出來了。

先不說場景，就他這種對純技術的追求也值得我們學習，現在大家都在談框架，有多少人願意正真的從微小的事情做起？當年 Webpack 剛出來的時候，有多少人看好呢？

要不， @王駱菲，大腰子，轉 antd 試試吧？

都在說轉antd，最近剛好在造這個輪子 https://vuecomponent.github.io/ant-design ，最初做的時候也有想過React-to-Vue做的事情，不過最後放棄了，這些組件都是人肉去轉的，如果 @王駱菲有要轉antd，可以交流下，或許能夠提供一些幫助。

PS：該組件庫已完成組件完全按照antd 3.X 100%功能實現，0樣式更改，90%邏輯復用

看了太多vue版本的antd，大多已經中途放棄，已經實現的組件也都是閹割版，看了一些這類庫，棄坑和閹割的部分原因大概是這些開發者對react不夠熟悉，只是復用樣式，然後去寫邏輯，成本實在是高。

有想法就去實現，非常欣賞這種行為~

我也說下我自己的看法：

以我和這兩者交往多年的經驗來看，我不看好任何通過 AST 硬轉的方案，不管是 React To Vue 還是 Vue To React。原因很簡單，兩個不管是從性格還是外貌都完全不相同的兩人，硬是把其中一人變成另一個人，那相處起來是很艱難的。

那比較理想的方案是什麼？

我覺得應該 Vue In React、Angular In React。

思路也已經有了~ 在 React 的基礎上，通過插件化配置，一鍵使用任何 Vue 組件甚至 Angular 組件，而不是通過 AST。

首先說我的態度，支持！

沒什麼好說的，也沒什麼諷刺的，有沒有意義是看其出發最初目的的，有很多小工具，在大眾看來都是沒什麼意義的，但是在某個公司，某個場景下，就是一款非常牛x的工具。

真正做過項目的人一定知道，哪怕是把淘寶抄過來，碰到的問題也會跟淘寶當初做出來的時候不一樣，每個公司，每個項目，都有不同的人，不同的問題，你看似沒意義的事情，別人那邊意義可大了。

或許，這個react轉vue現在看起來還是沒什麼意義，但是至少有人去做了，證明人家動腦了，學會解放了一部分生產力（可能只能轉幾個簡單的組件），但是我們說DRY原則，能少寫代碼，就少寫代碼，越少代碼越好維護。

轉Ant太難了，試試轉一下我剛開源的組件呀～

demo預覽地址：預覽地址（支持手機噢）

215566435/Dragact?

github.com

徹底一點，把 antd 轉了吧

假設足夠好的話

優點： write once, shyea jibar run

缺點：培訓機構不知道該教什麼了

謝邀此工具作者在我們團隊，叫王駱菲人稱腰哥，為什麼叫腰哥？因為他說他天生腰好，每周練習一次鋼管舞。

看了各種評論，先不說這個工具能有多大的使用場景，在浮躁的今天，作者能靜下心來在完成自己手頭工作的基礎上能研究vue和react並且還能寫出一個這樣的轉換工具，而且還能將我司90%的react組件轉換成功，這本身就是值得稱讚的事情。

@寸志@王駱菲期待後續更多的工具，做工具之前其實可以做做市場調研，這次至少炫技成功了，為團隊又爭了一次光。

我個人也希望能通過此工具在市場的表現能得出現在有多少公司在同時玩react和vue，多少公司想從react轉vue。

最後，大家可以進入前端神器：一行命令，React 組件轉 Vue 組件!，裡面有我們工具討論群的二維碼，歡迎對這個工具感興趣的同學加入。

先不說是不是實用，人家好歹辛苦做個開源出來，用的人多自然火了，沒人用也就死了。見著別人代碼二話不說先踩一腳是什麼毛病？文人相輕？

如果 antd -&> antd-vue，那確實是太強了，

首先我是佩服作者的勇氣和毅力，能搞出一個這樣的工具

但是從有工作經驗的人來說，這種ui互轉的情況，能不出現就不出現（如果出現，基本就重寫了），這都是風險極高的操作，很難完全覆蓋你所有的需求，再說了，如果有些特別複雜的組件，用了什麼奇技淫巧，那基本很難了

本來React和Vue就是兩套技術棧，可以這樣說，每個技術棧里都基本有相對完善的生態圈了，能夠出現這種生態圈的轉換的情況，我覺得有可能是「政治正確」，或者「科學實驗」性質的比較多（讓我想起一部電影《變蠅人》），否則在技術選型初期，這種風險就該規避掉了

這種轉換的例子，我之前看過一篇文章，國外的一個例子，但是還是後端語言的轉換，具體細節不清楚了，貌似是說公司接手了一個項目用的是XX語言，團隊用的是YY語言，但是這兩個項目必須怎麼著對接上（細節忘了），團隊很多人說那重寫吧（但是耗費時間肯定長），在項目開發了兩周之後，並且大家苦不堪言之後，其中一個大神說，他已經把XX語言的項目編譯成了YY語言了

在前端，我可能經驗少，還沒遇過非得轉換技術棧的業務場景，因為前端，你一個頁面用5個技術棧都沒啥問題，可能唯一的問題就是【數據管理】了

知乎react是政治正確

再次膜拜一下大佬。使用場景作者已經回答了。同為前端開發者，能靜下心來開發一個工具，實屬不易。

而且我們大多數人只是想想做個輪子，可是真正付出行動又完成了的又有多少呢。

作者精神可嘉，非常值得學習。

支持

感覺很好的工具，vue和react的差異本身就很小，切換起來本來就是零成本，何必酸呢……

React 技術棧表示

這樣就可以寫 React 同時獲得 Vue 的性能了（

會有，而且會很常見，這種情況往往發生在公司組織架構調整的時候。

如果同一家公司的前端團隊分散在不同的部門或項目組，大家自由技術選型，你用 Vue、我選 React、他用 Angular。

某天，公司要做組織架構調整，Vue 技術棧的團隊要接手 React 的項目，或者其它。

。。。

徹底一點吧，把angular也轉了吧

不過講道理...我所在的公司...也沒這種需求...

看了作者回答==

沒有嘲諷意思，作者和工具都很流弊

用這個工具轉換的話能帶來性能上的提升嗎？