https://inertiajs.com/who-is-it-for 這套的想法挺有趣的
用傳統的 SSR 處理 views 的 data 最終的 view 又交給 front 處理
Threadhttps://inertiajs.com/who-is-it-for 這套的想法挺有趣的
18 messages · –李 服 我對JS以及相關framework沒有很了解， 有些可能不太成熟/菜鳥新人的疑惑。 對JS的記憶還在以前LAMP的時代，當時剛出HTML5， 有一大堆HTML5的實作範例， 是用html5的div tag將畫面位置切分，部份畫面資料是用JS去跟後端要JSON然後render。 切畫面時，其實只是用CSS移動div，onFocus的div如果沒資料就去要JSON，有資料就不動作。 （我自已也有用過HTML5/JS/CSS，無frameowrk實作過這樣的網站） 然後先前看大家在討論CSR/SSR的framework， 我去google後，發現CSR只做了一半上述的行為， 還有lazy loading、code splitting的相關分類。 直到看到這個inertia，才感覺7/8年前就已經有的概念，有了完整的framework實作， 但看起來這樣的實作似乎不是業界常態？ 好奇想問是我對SSR/CSR的觀念認知錯了？還是哪裡有什麼誤會或錯誤？唯 M 首先你對於傳統開發的認知沒問題，這邊也不少人是從最早的 HTML / JS / PHP 大雜燴的時代走過來的，包含我就是 至於這個 直到看到這個inertia，才感覺7/8年前就已經有的概念，有了完整的framework實作， 但看起來這樣的實作似乎不是業界常態？ 他的好處很明顯，前端用類似後端的方式渲染，提升了前後的的耦合度也方便了 web 前端開發。 但他的缺點也很明顯，那移動端需要的後端怎麼辦？是不是又得另外開發API？ 想通這點你就會想通為何現代開發方式（CSR）逐漸變成主流 也就是說，如果你的應用只有 web，那採用 inertia 方案完全沒有問題，但你的方案包含移動端 app 就不是那麼合適了服 M loading 跟 call api 完全沒有關係喔 首先 CRS 的 resource 會先 loading 完，但不一定包含預先 call api，而是動態決定，比如使用者還沒有登入，自然不會先去 call login api。 什麼方式和後端加載資料則要看前端的定義，比如這個頁面的列表渲染就會call list 來渲染 ui li，那麼當前端渲染到 ui li時即會 call api 取得資料進行渲染。 而登入則是檢查到頁面需要登入而使用者尚未登入，也只是先route 到sign in page 提示使用者點擊登入。 也就是說何時向後端取得資料，完全是看前端的設計。 lazy-load 則是渲染頁面有需要用的部分才進行 loading，主要是為了避免首頁即 loading 全部的 SAP 導致首頁 loading 過慢問題服 M F M 李
服 M M 如果你熟 PHP laravel，那麼拿 laravel-mix 來實現 laravel-mix + vue，由 laravel blade 實現 SSR，再由 Vue.js + app.js 實現CSR。 這個實作的過程應該就會令你印象深刻 檢視原始碼 前者 載入完成即渲染完成 <div> <ul> <li>1</li> <li>2</li> <li>3</li> </ul> </div> 後者 載入完成後才開始渲染 <div id="app"> <!-- route outlet --> <!-- component matched by the route will render here --> <router-view></router-view> </div>服
李