New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Road to SPA #452
Comments
I totally agree with you and your proposal and it definitely follows my idea of Crowi's long term roadmap. I'd like to open ideas wether Redux is good for state and data flow management library or any other options at this moment? |
IMO: There are two reasons for choosing Redux:
If need to satistfy only 1, React's Context API is enough. |
Thank you :) |
|
Go on to be approved status :) |
Finally, converting codes to TypeScript and introducing styled-components have been completed! |
May I take |
@saitoeku3 Yes, please! Thank you |
Implementation guideline for migrating to React componentsSince not all of the existing codes are implemented with the same policy, I'd like to show you the basic policy here. Basic policy
FYI
|
I want to do |
@okonomi Sorry for the late reply |
I want to work on |
Please! Thanks |
Overview
Currently, views are built with Template Engine (Swig), jQuery and React.
I propose migrating to SPA based on component orientation to achieve better user experience and development experience.
Why
Because I want to eliminate the waste of communication with the back-end and rendering at the time of page transition for migrating to SPA as a modern front-end application that runs at high speed.
Implementation flow
Let rendering responsibilities come near the front-end
First, rewrite templates written in Swig to React components with appropriate granularity.
If the target depends on jQuery, it also rewrites to React component.
From now on, React components create in Functional Component, define types in TypeScript, and define styles in styled-components.
Front-end holds global state
Adopt Redux to manage global state at front-end.
After being injected into HTML from back-end, the state managed by the Crowi instance, etc. will be managed by Redux at this point.
Recently, react-redux supported the hooks API in React v 7.1.0.
Adopt react-redux@v7.1.0 to connect to Store using hooks.
https://github.com/reduxjs/react-redux/releases/tag/v7.1.0
Front-end responsible for page routing and rendering
Introduce React Router and route components on front-end.
As a result, back-end has API, static file, fallback to SPA routing definitions only, and front-end is responsible for page routing.
In addition, global level state is not injected from back-end because the browser does not cause page transition.
At this point, all Swig templates are not present in back-end, and front-end is responsible for rendering the page.
Furthermore, almost all styles are migrated from SCSS to styled-components by componentizing even top-level elements.
Tasks
react-helmet
Contributing
I created this proposal to more people be able to participate in the discussion and implementation by writing down and publish the specification and implementation flow before implementing a architecture or function that requires bold changes.
Please provide review or feedback on this proposal in this Issue comment. I look forward to your contribution🙏
Japanese
概要
現在のCrowiのビューはTemplate Engine (Swig)とjQueryとReactで構築されています。
より良いユーザー体験と開発体験を実現するためにコンポーネント指向に基づいてSPAに移行することを提案します。
何故やるか
ページ遷移時の通信やレンダリングの無駄を無くし、高速に動作するモダンフロントエンドアプリケーションとして実装をSPAに移行していきたいから。
実装の流れ
レンダリングの責務をフロントエンドに寄せる
まず、Swig で書かれたテンプレートを適切な粒度でReact コンポーネントに書き換えます。
書き換えた対象がjQueryに依存されていた場合はjQueryのコードもReact コンポーネントに書き換えます。
これから作成するReact コンポーネントはFunctional Componentで作成し、型をTypeScriptで、スタイルをstyled-componentsで定義します。
フロントエンドがグローバルレベルの状態を保持する
フロントエンドでグローバルレベルの状態を管理するためにReduxを採用します。
バックエンドからHTMLに注入された後、Crowiインスタンスなどで管理されていた状態はこの時点でReduxで管理されるようになります。
最近、react-reduxはReactのv7.1.0でhooks APIをサポートしました。
hooksを使ってStoreに接続するために、react-redux@v7.1.0を採用します。
https://github.com/reduxjs/react-redux/releases/tag/v7.1.0
フロントエンドがページのルーティングとレンダリングの責務を持つ
React Routerを導入し、フロントエンドでコンポーネントのルーティングを行います。
結果として、バックエンドはAPI、静的ファイル、SPAへのフォールバックのルーティングのみの定義を持ち、、フロントエンドがページのルーティングの責務を持つようになります。
また、ブラウザによるページ遷移が発生しなくなるため、グローバルレベルのステートはバックエンドから注入されなくなります。
この時点で、全てのSwig テンプレートはバックエンドに存在しなくなり、フロントエンドがページのレンダリングの責任を持つようになります。
更に、トップレベルの要素までがコンポーネント化されることで、ほぼ全てのスタイルがSCSSからstyled-componentsに移行されます。
タスク
貢献する
大胆な変更を要する機構や機能を実装する前にその仕様と実装の流れを書き下してオープンにすることでより多くの人が議論や実装に加われるようにするために、この提案を作成しました。🙏
この提案に対する意見をこのIssueのコメントで教えてください。あなたの貢献をお待ちしています
The text was updated successfully, but these errors were encountered: