正真正銘のReactだけの不純物なしでReact入門
Reactのチュートリアル、たくさんありますよね。どれも質が高く、どこから手をつければいいかわからなくなっちゃいます。 ですがやはり巷のチュートリアルには面倒な問題もあります。今回は面倒ごとを全部すっ飛ばしてReactでのウェブアプリ作りに入門してみましょう。 Reactを始めるには、まずあれとこれとそれとどれと…… Reactやるには、まずNode.js入れてbabel入れてreact入れてreact-router入れて、ついでにredux入れてreact-redux入れて、redux-saga入れて…… Reactめんどくせえ！！！ってのが正直なところだと思います。はい、私もそう思います。ただ、まあ、色々必要なのも事実なので……。 それでもやっぱり「ReactやるならReactだけやりたい。他はどうでもいい」という気持ちは簡単に捨てられるものではありません。そこで今回はそういう面倒全部
#AMPConf 2019で発表された検索関連の最新AMPニュース――amp-scriptやSXG、AMPストーリーなど
[レベル: 上級] 東京の六本木で 4 月 17 〜 18 日に開催されている AMP Conf 2019 に参加しています。 1 日目の基調講演から検索に関係する部分をピックアップします。 <amp-script> コンポーネント [05:34] AMP ドキュメントで、独自の JavaScript を実行可能になりました。 現状では、AMP が定義した JavaScript しか AMP では利用できません。 サイズが 150KB以内（圧縮前）などの制限はありますが、AMP JS 以外の JavaScript が使えるようになるのは大きな変革です。 詳細は公式ドキュメントを参照してください。 Next.js [06:33] Next.js が AMP を正式にサポートしました。 React の SSR が AMP で利用可能になります。 詳細は Next.js の公式アナウンスを参照し
Content Security Policy Level 3におけるXSS対策 - pixiv inside
こんにちは、セキュリティエンジニアのkoboです。ピクシブには2018年4月に入社しており、セキュリティ観点でのアプリケーション開発や脆弱性報奨金制度の運用などを行っています。 本記事では、現在ピクシブの一部のサービスで取り組んでいるContent Security Policyについて知見を共有します。 概要 Content Security Policy (CSP) は、XSSを主としたウェブアプリケーションセキュリティの問題を軽減するために考案されたブラウザのセキュリティ機構です。 ウェブアプリケーションは、 Content-Security-Policy ヘッダをHTTPレスポンスに含めることで、意図していないJavaScriptの実行やリソースの読み込みをブラウザ側で制限することができます。 CSPは2012年頃よりブラウザに実装されていますが、2016年のGoogleの調査によ
Google Apps ScriptsでTypescriptが超簡単に使えるようになった！ - アクトインディ開発者ブログ
morishitaです。 Cloud Functions と並ぶ(?)Google のサーバレスな JavaScript 実行環境といえば Google Apps Scripts（GAS）です。 GAS ってあの Excel で言う VB スクリプト環境のようなものでしょう？ と思ったあなた！ このエントリでその認識が変わると思います。 以前は使いやすいとは言い難かったGASですが、最近は使いやすくなってきました。 といっても、GAS 自体がアップデートされたのではなく周辺ツールが整備が進み開発・運用しやすい状況が整ってきたからです。 そして、なんと最近Typescript でとても実装しやすくなったので、それをご紹介したいと思います。 google/clasp 以前の GAS は Web エディタ上でしか実装できず、コードを VCS で管理することもままならない状況でしたが、Google
iframe sandbox は万能ではない - 葉っぱ日記
HTML5で導入されたiframe要素のsandbox属性は、そのiframe内のコンテンツに対しJavaScriptの実行を始め様々な制約を課すことでセキュリティの向上に役立つ機能である。例えば、以下のように指定されたiframeでは、iframe内からformのsubmitなどはできるが、iframe内でのJavaScriptの実行やtarget=_blankなどによってウィンドウを開くことなどは禁止される。 <iframe sandbox="allow-forms" src="..."></iframe> sandbox属性に明示的に allow-scripts という値を指定しない限りはiframe内では直接的にはJavaScriptは実行できないが、かといってiframe内から間接的にJavaScriptを必ずしも実行させることが不可能かというとそうでもない。 sandbox属性
[追記]スクリプトでスクリプトを停止させることの難しさ。
「サイト上で実行されるプログラムについて同意を確認するためのプログラム」という記事で、MutationObserverを使ってscriptタグがDOMに追加させるタイミングでremoveを行うという力業を試してみたのですが、どうにも完全に実行を停止するのは難しいようです。 もともと、本来はheadタグ直下で実行すべきコードを記事文中内で実行しているため、記事以前に記述されているscriptに関しては実行を止めることができていなかったのですが、ほかにもasync属性が設定されているスクリプトに関してはこの方法では実行を止めることはできないようです。 また、一度ページが表示されるとキャッシュが残るため、2回目にページを表示した際に正しく動作しないようです。 サードパーティのスクリプトをフックして実行を制御するのはなかなかに難問でした。 [追記]検証ページつくってみました。 ※リンク先の検証ペー
![[追記]スクリプトでスクリプトを停止させることの難しさ。](https://cdn-ak-scissors.b.st-hatena.com/image/square/fd902abb89b1b4fc328a4b2ee96c2be18ced2e8d/height=288;version=1;width=512/https%3A%2F%2Fgunmagisgeek.com%2Fblog%2Fwp-content%2Fuploads%2F2018%2F06%2F34247407796_ca570b37e6_k.jpg)
サイト上で実行されるプログラムについて同意を確認するためのプログラム
昨今、クライアントサイドでプログラムを実行するリスクが高まっています。 そこで、ページ上で実行されるプログラムについて閲覧者に同意を求めるプログラムをこのページに埋め込んでみました。 ひとえにクライアントサイドで実行されるプログラムといっても様々なものがあります。 例えばこのブログはWordpressで作られていますが、使用しているテーマは様々なJavaScriptライブラリを外部から読み込んでいますし、Google アドセンスのような広告を表示するためのプログラムや、Google アナリティクスのようなアクセス解析を行うためのプログラムも閲覧者に許可なく実行され、CPUやメモリ、電力といった閲覧者のリソースを消費します。 また、このブログに掲載しているデータビジュアライゼーションや地図コンテンツは、複雑な計算処理をクライアントサイドで行う為、非常に負荷の高いプログラムがユーザーサイドで実
Svelte で依存のないコンポーネントを作る
特定の UI ライブラリへの依存をなくしたいアプリのフロントエンドを作っていると、どんなアプリでも使うようなコンポーネントが繰り返し出てくることに気がつきます。例えば、日付入力をカレンダーで選択させるようなコンポーネントは、日付入力機能をもつすべてのアプリで使用したいです。こういった汎用的なコンポーネントはだいたいライブラリが世の中にあるので、それを使うことが多いですが、最近よくあるのが、jQuery に依存しているから使えない (使いたくない) というケースです。最近のプロジェクトではモダンな UI ライブラリ (Vue とか React など) を使い、jQuery を使っていないことが多いので、そこにさらに jQuery 依存のコンポーネントを入れてしまうと、読み込むスクリプトサイズが大きくなってしまうのが主な理由です。 例えばこういうのを使いまわしたい (flatpickr の動作
フロントエンジニア必見！JavaScriptのエラーログ収集方法 - IDCF テックブログ
こんにちは、UX開発部の橋口です。 Webサービスを開発するうえで、JavaScriptは絶対的に使われる技術だと思います。 みなさんもJavaScriptでエラーの調査をする際に、クライアントで実行されるためエラーの内容やどこで発生したかが分からなかったり、問い合わせ内容の再現ができず困ったことがあるのではないでしょうか？ 解決の糸口を作るためには、クライアントサイドで発生したエラーに関する情報を収集してあげる必要があります。 JavaScriptのエラーログも収集できる著名な製品もありますが、クラウド環境への導入の場合には高額になってしまったり、独自に解析する場合でも、環境などを用意するのも大変ですし管理も大変です。 そこで、今回の記事はトレジャーデータサービス by IDCFにJavaScriptのエラーログを収集する方法について紹介します。 課題 JavaScriptのエラーを収集
Node.gs： Node.js スタイルでの Google apps script 開発手法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Google apps script のオリジナル・オンライン開発環境は、小さなプログラムをちゃちゃっと書いては捨てて動かすのにはとても便利ですが、ある程度大きなソフトウェアを開発・運用するとなるとそのままでは難しくなります。 特に Google apps（今は G-Suite ですね）を利用した業務システムの開発・運用をしている人は、業務システムは継続改善がつきものですし、苦労されているのではないかなあ・・・と思います（私もです！）。 そこで本稿では、Google apps scriptアプリケーションを Node.js のように複数
Goだけで作るフロントエンド
Go のシンタックスだけで HTML とスタイルと JS を構築する「Vecty」というフロントエンド開発キットの紹介 先日 Umeda.go#3 にて登壇して Vecty を紹介しました。資料はこちらです。 Vecty とは？ リポジトリ: https://github.com/gopherjs/vecty GopherJSむけの React-like な frontend development kit です。 GopherJS について 前に書いた紹介記事を参照 Vecty の主な機能は GopherJS の Go 記述を JS へのトランスパイル機能を利用します Go のシンタックスのみで HTML とスタイルとイベントハンドリングを記述 HTML 記述ツリーをコンポーネントとして定義する支援機能 コンポーネントツリーを初期レンダリングする機能 仮想 DOM のようにコンポーネント
ECMAScriptの使い方
プロポーザルのステージの進み方 2ヶ月に1度行われるTC39のミーティングでプロポーザルのステージを更新 ミーティングの議事録は tc39/tc39-notesで公開 毎年のECMAScriptをリリースするタイミング(6月)で、Stage 4のプロポーザルをマージ ECMAScript 20XXとしてリリース なぜ仕様策定プロセスが変わったのか ES2015以前: すべての仕様の合意が取れてからリリース ES2016以降: 合意が取れた仕様からリリース 変更理由: ECMAScriptのリリースに長い歳月がかかり言語の進化が停滞した 歴史的失敗: ES4では多くの変更を入れることを試みたが、TC39内でも意見が分かれ最終的に合意できなかった これにより言語の発展が数年間停滞した[^1] [^1]: Programming Language Standardization: Pattern
ES Modules への橋渡しとしての nomodule 属性 | blog.jxck.io
Intro ブラウザにおける新機能の利用においては、非対応ブラウザの考慮も必要となる。 ES Modules の利用においても、いかに非対応ブラウザでフォールバックの手段を提供するかが課題となっていた。 今回は、Modules の対応/非対応を切り分けるための仕様である nomodule 属性を解説する。 script type module classic script (module ではない JS) は、<script> で指定すると、取得解析しそのまま実行される。 type は省略されることが多いが、その場合 text/javascript と解釈されている。 <script type=text/javascript src=bundle.js></script> 一方、module script (module として実装された JS) は、import/export の処理や依
TypeScriptにpluginがやってくる 使ってみよう編 - Qiita
はじめに どうも、 @Quramy です。 前回の投稿から随分日が経ってしまいましたが、この投稿はある意味で前回投稿の続編的な内容になります。 今日はTypeScript 2.3から導入されるLanguage Service Extensibilityと呼ばれている機能についてまとめてみようと思います1。 どのような変更なのか TypeScript Roadmapのリンクを辿っても、https://github.com/Microsoft/TypeScript/pull/12231 に行き着くだけで、パッと見は何の機能なのかよく分かりません。 このPRの実装を眺めると、次の機能が見えてきます。 tsconfig.jsonのcompilerOptionsに"plugins"というキーが追加されている pluginsに指定した内容は、TypeScript本体からresolveされる すなわち、
Node学園 23時限目 アウトラインメモ
Node学園 23時限目 (今回はリクルート（東京駅）でやります！) - connpassに参加してきたのメモ npm@4、npm@5 node-gakuen-201610.md npmは後方互換性を重んじている Node.jsにbundleされているので npm@2のbreaking changeについて backwards-incompatible change to the way npm run-script handled its arguments npm@3 flat directory npm@2そのまま使い続ける人もいる 大きな変更は移行の壁になるという話 npm@4 Release v4.0.0 · npm/npm npm 4は小さな変更にした prepublish が npm install 時に実行されるのは Deprecated prepublishOnly と
『Riot超入門』
こんにちは。タクスタでフロントエンジニアをしている今井(@imakei_)です。 現在リニューアルしている"宅スタ"、あたらめ"takusuta"でweb開発を行っております。 (リニューアル詳細はこちら) 今回はtakusuta(https://takusuta.com)で用いてるJavaScriptライブラリーRiot(http://riotjs.com/)をテーマに書きたいと思います。 Riotとは A React-like user interface micro-library
JavaScriptの読み込みにおける非同期スクリプト注入の悪影響 | POSTD
Synchronous（同期）スクリプトは効率が悪い。というのも、ブラウザにDOM構築をさせ、スクリプトを読み込ませ、残りのページをリロードする前に実行してしまいます。今さらな話ですが、これがわれわれプログラマがasynchronous（非同期）スクリプトをよく使うようになった理由です。ここに分かりやすい例があります。 <!-- BAD: blocking external script --> <script src="http://somehost.com/awesome-widget.js"></script> <!-- GOOD: remote script is loaded asynchronously --> <script> var script = document.createElement('script'); script.src = "http://somehos
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - GerbenJavado/LinkFinder: A python script that finds endpoints in JavaScript files
Tangled World of Web Technology ― Are we safe?
Not Found
