Front-End Deep Dive
https://gyazo.com/c8116a7583d0a14a1398a6e3d3f04526
会社紹介
Smart HR
Ruby on Rails
React TypeScript
https://gyazo.com/77879b365b765509218d9580aeb42b5f
Another Works
複業クラウド
Ruby on Rails
Next.js
「Web Components を使ったウィジェット埋め込みの話」
Web ComponentsをLitでラップ
Web Componentsとの通信はDispatchとSubscribeのみ
以下両方のパターンに対応するためにWeb Components
従業情報の編集画面はhaml + jQuery
申請フォームはReact
wintyo.icon まず統一する方を先にするべきな気がする。。
3rdパーティとして埋め込みウィジェットを解放する場合はサンドボックスを考える必要がある
サンドボックス化検討
iframe
wintyo.icon これはもうWebComponentsじゃなくても良いよねw
QuickJSをWasm化する
Web Worker
ShadowReaml API
wintyo.icon Reactで全て統一されていたらWeb Componentsは不要そう
「Next13新機能 App Routerにどう向き合うか？」
app/から呼び出されるコンポーネントは基本サーバーコンポーネントになる
styled-componentsやemotionなどのランタイムCSS in JSはサーバーコンポーネントは使えない
メリット１：直感的にかける
code:text
app/
- user/
- error.tsx
- loading.tsx
- layout.tsx
- page.tsx
- error.tsx
- loading.tsx
- layout.tsx
- page.tsx
モーダルの実装が楽になる
wintyo.icon このメリットが今一分からない。。
機能
Parallel Routing
Interceptor Routing
Server Components
SSRとの違い、コンポーネント単位で作っているようなコンポーネント
メリット
リスク回避
サーバーコンポーネントから呼ぶAPIに対してIP制限をかけられる
直接APIを実行されないため、クローリング対策やセキュリティリスクを軽減できる
利益
Pocをやる際にはDB直接繋いで素早く検証できる
キャンペーン系が管理しやすくなる
懸念
APIサーバーも存在するとなると、SPAよりもコストは高くなる
ランタイムCSS in JS
Styled Components
Emotion
ゼロランタイムCSS in JS
linaria
macaron
Next.jsからのおすすめ
CSS module
tailwind css
wintyo.icon やっぱりCSS Moduleの方が良いのかなぁ
「元フロントエンドエンジニアからみたデザイナーとの協業と実態」
https://gyazo.com/b782f1d72ba77a9074f9addbde4682d7
https://gyazo.com/ce896a35334b3783ac7be5b7117108cd
UIモデリングをしていた