新規事業開発での技術選定の意思と意図 (フロントエンド編) - Sansan Tech Blog
こんにちは、関西支店で新規事業開発室に所属するソフトウェアエンジニアの加藤です。Bill Oneという新規サービスの開発に携わっています。 バックエンド編の続きとして、フロントエンドで私たちが使用している技術やライブラリを振り返って、どんな意志と意図があるかを確認していきます。 Bill Oneは今年の1月ごろにピボットし、それまで開発してきたフロントエンドを全て捨て、1から作り直しました。ピボットの際に改めて技術選定を行い、それまで使っていたライブラリ等を見直したので、本稿ではピボット前後で変化した箇所を中心にフロントエンドの技術選定を紹介します。 前提 改めて前提です。私たちのチームで開発しているBill Oneは今年の5月にローンチしたばかりのサービスで、チームのエンジニアは5名です。開発しているアプリケーションはSingle Page Application (SPA) で、エンジ
ここ数年の流れについて 技術的側面 Webフロントエンド（ほぼTypeScript＆React界隈）において、オブジェクト指向（厳密に言うとクラスの利用）から脱却する流れがあります。原因は以下の2点。 クラスの継承の問題点が（IT業界全体に）広く定着したこと JS/TSの進化、Reactの進化、関数型言語の考え方などの影響により、クラスを用いてデータと関数群を紐づけるメリットが薄くなったこと 現状、設計レベル（実務的にはどの関数を纏めてモジュール化するのか、モジュール同士をどう繋ぎ合わせるのか、フォルダ割りどうするのか等）のノウハウがまだ固まっておらず、既存の設計論はそれなりに有効です。 コミュニティ的側面（政治） これらの流れはWebフロントエンドの中でもTypeScript＆Reactの界隈が主導しており、そのノウハウは長年絶対視されてきたオブジェクト指向を解体するような内容であったた
Brand-new Rich Text Editor Framework! 先日 Meta から新しいリッチテキストエディターのフレームワーク Lexical の OSS 化が発表されました。 一方で、 Meta が開発していた既存の React 用リッチテキストエディターフレームワーク Draft.js はアーカイブが決定されました。 実は自分は業務で Draft.js をめちゃくちゃ使っていて、発展に期待しつつウォッチしていたので開発が終了してしまうのが非常に残念ではあるのですが、代わりにより高度に抽象化されたフレームワークが公開されたのでこれはマスターするしかありません。 ということで調べたことをまとめていこうと思います。 執筆時点(2022 年 4 月)では正式リリースされていないので、本稿のサンプルコードは参考にならなくなる可能性があります。 概要 エディターを作るためのフレーム
【forが嫌い！可読性を上げたい！】楽するために学ぶ配列の高階関数(map, filter, reduce等) - Qiita
【forが嫌い！可読性を上げたい！】楽するために学ぶ配列の高階関数(map, filter, reduce等)JavaScriptリーダブルコード高階関数 複雑すぎるforの処理に悩まされたことはありませんか？ プログラミング習いたての頃、forに悩まされた記憶はありませんか？ また、業務で複雑すぎるfor文を見て、これくらい理解できないとやっていけないのか…と悩んだ記憶はありませんか？ 実はそのfor…もっと読みやすい書き方が出来て、簡単に読めるとしたら楽じゃないですか？ いやいや、単にもっと楽したくありませんか？ 今回は個人的に「苦手なfor文」の書き換え(map, filter, reduce等)について、短くなるだけじゃないところを紹介したいと思います。 コードを読む事に神経をとがらせて疲弊したくない人には、オススメしています。(頭を使う労力が減ってると信じたい...) 本記事につ
昨今のフロントエンド開発では、データをイミュータブルなオブジェクトとして扱うのが主流です。すなはち、データが変わるときはオブジェクトを書き換えるのではなく、新しいデータを持った新しいオブジェクトを作ります。最近ではオブジェクトがデータとしてプログラムのあちこちで取り回されることが増えて、一度余所に渡されたデータの中身が後から変更されるのは混乱をきたし設計が困難になるというのが主な理由です。 データを変更するたびに新しいオブジェクトを作るのは、特にデータが複雑になったりネストしたりしていると面倒だしプログラムの見通しが悪くなります。そこで使われるのが、データをイミュータブルに扱うためのライブラリであるImmutable.jsとImmerです。 データをイミュータブルなものとして扱うという目的はどちらのライブラリでも達成することができますが、現在では Immer のほうが開発が活発であり、独自
実践 Node.js Native ESM — Wantedlyでのアプリケーション移行事例 | Wantedly Engineer Blog
Wantedlyではこのたび、フロントエンドアプリケーションのひとつをNative ESM化しました。本記事ではNative ESM化の必要性と、必要な作業について説明します。 この記事の概要Node.jsにはNative ESMというモードがある。Native ESMはまだ普及していないが、ライブラリ側の更新が進み、移行が必要になりつつある。Native ESMをめぐる状況は (この記事の長さからわかるように) 色々複雑で、概念をちゃんと説明するだけでも大変。Native ESMへの移行にあたってはさまざまな困難が待ち受けている。Native ESMとは歴史的経緯から、JavaScriptには複数のモジュールシステムがあります。そのうちNode.js周辺でよく使われるのはCommonJS ModulesとES Modulesです。 CommonJS Modules (CJS) は実質的に
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
💣Webフロントエンドにおける関数型「風」プログラミングに関する個人的まとめ - Qiita
Meta の新しいリッチテキストエディターフレームワーク Lexical を調べる
Immutable.jsとImmer、ちゃんと使い分けていますか？