Discover the most popular JavaScript technologies of the year.
Discover the most popular JavaScript technologies of the year.
2017年版と2018年版でwebアプリケーション作成時のreactの（マイ）ベストプラクティクスを以下のリポジトリに、まとめてみたので記事にしてみました。 react-best-practices https://github.com/wheatandcat/react-best-practices/tree/master ちなみにタイトルは、その過程で2018年版に削除したpackageです（理由は後述） github サンプルコードの内容は、ログイン/ログアウト + fetchした内容を画面に表示するだけです （ただのサンプルなので、実装はハリボテです） 2017年版 https://github.com/wheatandcat/react-best-practices/tree/master/2017years 2018年版 https://github.com/wheatandc
この記事はJavaScriptの入門書として書いているjs-primerのthisに関する部分をベースにしています。 またjs-primerでは書けなかった現在時点(2018年1月1日)でのブラウザの挙動についてを加えたものです。 次の場所にjs-primer版（書籍版）のthisについての解説があります。 この記事と違って実際にコードを実行しながら読めるので、学習ソースとしては書籍版を推奨します。 書籍版: 関数とthis · JavaScriptの入門書 #jsprimer また、バグ報告やPRも直接リポジトリにして問題ありません。 asciidwango/js-primer: JavaScriptの入門書 おかしい場所を選択した状態で右下にある”Bug Report”ボタンを押せば、簡単にtypoとかのバグを報告できます。(PRでも歓迎) 前置きはこの辺までで、ここから本編。 この記
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
CSS isn’t going anywhere. A lot of the projects choose to style documents in JavaScript for wrong reasons. This article lists common misconceptions (myths) and the existing CSS solutions to those problems. Nothing in this article is meant as a personal attack against either a specific project or a person. I define “CSS in JavaScript” as using styled-components as this is the current trend for styl
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
Who? ジョージ エンジニア at Qiita＋Increments @jbucaran GitHub Twitter Qiita jbucaran.hatenablog.com 今まで作ってきた OSS は？ fly – Generator & Coroutine-based build system. fisherman – A concurrent plugin manager for fish. hyperapp – 1kb JavaScript library for building frontend applications. アジェンダ What is hyperapp? GitHub Documentation Examples Why hyperapp? How does it work? Differences with other libraries What n
Webpacker has served the Rails community for over five years as a bridge to compiled and bundled JavaScript. This bridge is no longer needed for most people in most situations following the release of Rails 7. We now have three great default answers to JavaScript in 2021+, and thus we will no longer be evolving Webpacker in an official Rails capacity. For applications currently using Webpacker, th
後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」 先輩「そうかそうか、やっと肩の荷がおりるな」 後輩「これ2016年に作ったシステムなんですよね。僕その頃まだ入社してないんで、最初の方から教えてもらっていいですか」 先輩「よしわかった。環境構築から順を追って説明する」 〜 先輩「まずはじめにnode.jsを入れる」 後輩「あ〜昔流行ったサーバーサイドでJavascript使えるやつですよね。このシステムnodeで動いてたんですね」 先輩「いや、nodeは使ってない」 後輩「え？」 先輩「nodeに付属しているnpmというパッケージマネージャーを使ってる」 後輩「なんでまたそんな回りくどいことを・・・」 先輩「当時はnpmが一番メジャーだったんだよ。今主流のN3(N3 is Not Npm)はまだ無かったしな」 〜 先輩「よしnode入れたな。じゃあnpm inst
この記事は、はてなエンジニアアドベントカレンダー2016の14日目の記事です。13日は id:astj による『Perl 6 のモジュールエコシステムの話とモジュールを公開する話 (2016年12月版) - 平常運転』でした。 こんにちは。Mackerelチームでアプリケーションエンジニアをやっている id:itchyny です。 Mackerelは、同じ役割を持つホストを束ねた「ロール」、そしてロールを束ねた「サービス」というまとまりでホストを管理し、一覧性の良いグラフ画面を提供しています。 ロールあたりのホスト数、そしてサービスあたりのロール数が増えると、グラフの画面のパフォーマンスに大きく影響します。 Mackerelチームでは大規模なサービスでも快適にグラフを閲覧できるように、継続的に画面のパフォーマンスを改善してきました。 本記事では、Mackerelのフロントエンドのパフォーマ
はじめに こんにちは、投稿開発部エンジニアの芳賀です。 既存のRailsプロジェクトの中でReact.jsを利用する機会があったので、その時にやったことについてまとめてみます。 私自身は普段RailsのサーバサイドとCoffeeScriptが中心で、最近のJavaScript開発環境についてあまりキャッチアップできていなかったのですが、それらの状況を把握しつつ試行錯誤で開発していった経験から、できるだけ「React採用してみたいけどJavaScript界隈よくわからない目線」で書いてみようと思います。 RailsでReact.jsを使ういくつかの方法 2016年時点で、RailsでReact.jsを使う方法はいくつかあって、どれを採用するかで悩みました。 vendor/assets/javascripts にreact.jsを置いて利用する react-rails gem を利用する br
JavaScript data grid with spreadsheet UI A front-end component that combines data grid features with spreadsheet UX/UI. Professional support included. Works with React, Angular, Vue, and plain JavaScriptGet Started What's new in v14.6.1 of October 17, 2024 → All spreadsheet featuresWhen you work with Handsontable, it's like you're working with Excel or Google Sheets. There's no steep learning curv
CodeceptJS is opensource MIT licensed testing framework. Works with your favorite frontend frameworks → Scenario Driven Write acceptance tests from user's perspective. Make tests readable and easy to follow. Driver Agnostic Run your tests via Playwright, WebDriver, Puppeteer, TestCafe, Protractor, Appium. The code is the same. Learn More
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
fluxxorとsocket.ioを使ってチャットを作った。大変ミニマムな感じの実装を心がけてて、今後何かWebアプリを作る時はこれを少し組み替えて作るぞというのを意識してる。ようするに低機能最低限でしょぼい。サーバー側はexpressとmongodb。 https://github.com/shokai/node-flux-boilerplate herokuでも動く https://node-flux-boilerplate.herokuapp.com/ クライアントはこんな実装 Fluxアーキテクチャ Reactはなんとなくわかってfluxをやるか、と思ったらflux npmの中がdispatcherしかなかった。 flux.DispatcherのwaitForの実装 まずこのへんを読んでフムフムなるほど（わかったようなわからないような）となる。 Flux | Application
クロージャとは クロージャは、言葉で説明するのが大変難しい概念です。 あなたは、自転車の乗り方を、口だけで説明できるでしょうか？ あなたは、螺旋(らせん)の形を、言葉だけで説明できるでしょうか？ ずばり、できないでしょう。 しかし、自転車に乗ることはできますし、針金で螺旋の形を作ることはできるでしょう。 「クロージャ」もこれと同じです。 だから、Wikipediaのこんな解説を見ても落ち込まないでください。 クロージャ (クロージャー、Closure) は、プログラミング言語において引数以外の変数を実行時の環境ではなく、自身が定義された環境（静的スコープ）において解決する関数のことである。 理解できないですよね？ 私もそうでした。 クロージャを既に知っている人にしか、この文章は理解できないでしょう。 クロージャを作るのは難しくない しかし、説明するのは難しくても、作るのは意外と簡単。それが
checkboxやradioのチェック状態を調べる際にはattrではなくpropを使うのが良い。 attrでも取れないこともないですが、propで取得する方が処理が早いです。 特にIEの場合、inputに対するdisabledの処理がものすごく重く、attrでdisabledやcheckedの処理を沢山していると、無駄に最悪な感じで負荷がかかります。 ##attrとpropの取得の違い## またこの２つは、同じ値を取得してるようで異なる値を取得するので注意。 例えば の場合、 チェック時 prop true attr checked 非チェック時 prop false attr undefined という全然違う値が返ってきます。 ##なぜ解釈が違うのか## attrは純粋に 属性における値 を取得するので、この場合は、 checkされてない ↓ checkedという『属性』がない！ ↓
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
