サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
WWDC25
medium.com/@terrierscript
React 16.8で有効となったReact Hooks。魅力的な点は多々あるが、個人的に気になっていたのがState管理部分。 ReduxのStateの単一管理とはまた違っていて複数のState、Contextを使うような感じになってくる。 ただやはり単一Stateの管理はそれはそれで良い点を感じていて、「いやいやuseState本当にぐちゃぐちゃにならないのか?」という疑問があったりもした。 このあたりを検証したいなーと思っていたところ、以前Dart Sassをブラウザで動かしたときに作ったトイプロダクトがコードがStateを複数持たせたりして「うわーっ!爆発するー!」ってなってたことを思い出して書き換えをやってみたのでその雑感などをまとめたい。 今回の主題はトイプロダクトだからやったことなので、「さあ今すぐみんなHooksだ!」という趣旨のものではない(多分そういうのは推奨されてない
先日なるほどデザインがお買い得になっていたのですかさず買ってしまった。(今更だがテイスト的にKindle版よりも出版物で買ったほうが良かったかもと思いつつある) 本の趣旨としてはWebよりも出版物のデザインにフォーカスしているといえる。とはいえデザインというものの基礎の話をしている本であり、それはWebについても考える部分は多いと感じた。 自分はエンジニアという役職で、デザインに関しては専門ではない、ただフロントエンドという部分においては、デザイナの理想にいかに近似させるかという部分は責務であると思っている。そういう人間にとっては「デザイナはどういう点に気を使っているか」という部分をノンデザイナーズ・デザインブックよりも専門的な点で知れる本といえるだろう。 Chapter3にあるグラフなどはエンジニアにもよく馴染みのある話だったり、写真の構図や配置による意図などは理解しておくと「ああ、この
styled-componentsとCSS-Grid組み合わせるとなんかいろいろ出来るぞ!みたいな事に気付いて、meguro.cssの枠に空きがあったので「ここで話すしかない!」みたいな感じで参加しました。前回はゴリッとJSなdart-sassの話をしてしまったのですが、今回はかなり趣旨に使い話ができた気がします。 ちょっと前から「もうちょっとUI(UXではなくあくまでUI)についてもう少し素振りしたいなー」みたいなことを思っててDaily UIをCollect UI 見たりしながらチマチマやっていた所でいろいろ脱線したのが今回の産物になります(電卓とかの例はまさにそれです) 元がデザイン素振りのためのものだったりするので、パフォーマンスだったりブラウザ依存とかは考慮してない夢の世界の話ですが、一部は真面目に使えるケースもあるんじゃないか?と思ったりもしています。 画的に地味ですが、タイム
デモとソースはこちら Demo https://dart-sass-bootstrap-demo.netlify.com/ (その3) Source https://github.com/terrierscript/dartystrap/ Soruce (parcel-plugin) https://github.com/terrierscript/parcel-plugin-darty その1だけの簡素版もあったので貼っておく(こっちの方がさっくり動いている感がある) https://dart-sass-browser-sample.netlify.com/ https://github.com/terrierscript/dart-sass-browser ソースはアレな具合なところ多いがご勘弁願いたい。 本当は元々Bootstrap4のカスタムビルド的な話をしようと思って練っていたら
お付き合いのある株式会社エフコードさんの社内勉強会で発表するお仕事をさせていただいたのでそのまとめ。 お題目としては「なんかフロントについて話して」とふわっとボールをいただいて、さてどうしようかなーと色々考えた末に、フロントエンドの歴史についてという題目にしてみた。 比較的サーバーサイドどっぷりな人が多いのもあったので、なるべくライト気味に、とか色々考えてみて、フロントエンドへの恐怖感取れたら良いよなあと思ったというところ。 地味に外で話すということをやったことがほとんど無い人間なので、わりとがっつり練習した(多分スライドも喋りにあわせて作っているので、スライドだけ見てもあまり良い資料ではないかも) なんとなく大道芸人が興行に行くような気持ちだったと思う(大道芸人やったことないけど) 当日も手応えがある反応をいただけたのでよかった。 作ってみてどうだったか最初「いや、こんな老害みたいな話し
自分はzennなどに技術記事を趣味で書くことがあります。 書き始めたのはエンジニアとして中堅ぐらいになった頃からで、それ以前は全然書いていませんでした。…
先日、reduxのメンテナであるMark EriksonさんがBlogged Answers: Redux — Not Dead Yet! という記事を書いていて「はーなんだろうなー」と流し読みしていた。 そんな折、React 16.3 がリリースされ、Context APIが刷新されたのを見て、「あ、これは確かに向き合い方ちょっと変わるかも」というのを思ったのでまとめてみる。 Redux — Not Dead Yet!を要約する元記事をざっくり要約してみるとこんな感じ Reduxはどこにも行かないよ。メンテしていくし、役割もあるよContext APIによってReduxを置き換えられるパターンはありえるよ。ただその場合、最初からReduxいらなかった可能性あるよGraphQLがReduxを置き換えることはあるかも。でもReduxのほうがハマるパターンもあるよ最近Dan Abramovさん
TL;DRloadable-components is 良い。 まえがきdynamic importを使ったcode splitngをする際、Reactだとラッパー的なものを実装しないといけなくて若干面倒がある。 ライブラリも存在しているのだが、reactの公式で紹介されているreact-loadableはissueが受け付けられてない状況になっていたりするのであんまり使いたくないなーと感じていた。 react-async-component / react-code-splittingもあったが、どちらも導入するほどの気持ちにならなかったので、だいたい自前になっていた。 「みんなどう思ってるんだろうなー」と何気なくissueをあさっていた所、loadable-componentsを見つけた。smooth-codeという会社が作っているらしい。 https://github.com/rea
ここ最近redux-observableを触りまくって、過去何度も挫折してたRxがちょっとわかるようになってきた。 そこで「redux-observableって実はRx入門に良いのではないか?」と感じたのでちょっと自分なりの考えをまとめてみる。多分@ngrx/effectsでも同じ事が言えると思う どんな点redux-observableはRx入門に良いと思うのか?その1.「Everything is stream」はちょっと難しい。「Actions is stream」で考えると難易度下がるRxといえば「Everything is stream」。だが、Rx初学者の自分にとってハードルになっていたのではないかな?と感じた。 cycle.js、recomposeで挫折していた話recomposeではcomponentFromStreamでvdom$とコンポーネントがstreamになっていた
このページを最初にブックマークしてみませんか?
『medium.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く