タグ

JSONとidに関するkyo_agoのブックマーク (5)

  • Slack ペイロードに含まれる response_url を完全に理解する - Qiita

    response_url を理解しよう この記事では、Slack アプリを作ったことがある人でもあまり馴染みがないかもしれない response_url という仕組みについて網羅的に説明してみたいと思います 1。 response_url は、スラッシュコマンドやショートカットのようなユーザーと Slack アプリの間で直接的なインタラクションが発生する機能のペイロードに含まれるものです。Incoming Webhooks や chat.postMessageで Slack に通知を送るだけの連携からもう一歩進んで、よりインタラクティブな Slack アプリを作るとき、この機能をうまく使うと、より良いユーザー体験を実現できるでしょう。 なお、この記事では日語でできる限り丁寧に説明していきますが、こちらの英語のドキュメントにも多くの内容は書かれていますので、合わせて参考にしてみてください。

    Slack ペイロードに含まれる response_url を完全に理解する - Qiita
  • データフェッチはuseEffectの出番じゃないなら、結局何を使えばいいんだ

    ショートアンサー React 18 からのフックである、useSyncExternalStore を使えばいいようです。 ※ useEffect がまったくだめだというわけではありません。 ※ クライアントサイドレンダリングのみを考えています。サーバーサイドレンダリングを考慮すると違った答えになるかもしれません。 サンプルコード 次のような useData フックを作ってみます。 JSON API の GET レスポンスを返すシンプルなものです。 実験をしやすいように、リクエスト URL を変えるボタンを置いてあります。 import { useEffect, useState } from "react" export function SearchResults() { const [id, setID] = useState(1) const todo = useData(`http

    データフェッチはuseEffectの出番じゃないなら、結局何を使えばいいんだ
  • 実行環境依存のコードに対してテストを書く考え方

    社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや node.js 固有の環境をインラインで記述してしまうことが多々あると思います。 あえてダメダメなブラウザ向けのエントリポイントの例を書きます。 // main.ts let id = localStorage.get('id'); if (!id) { id = `${navigator.userAgent}-${Math.random()}`; localStorage.set('id', id); fetch('/auth', { method: 'POST', credentials: 'include', body: JSON.stringify({ id, at: Date.now(), }), headers: {'Content-Type': 'applicat

    実行環境依存のコードに対してテストを書く考え方
  • Elm で不正な JSON に厳しすぎる問題についてのメモ - ジンジャー研究室

    長いだけで中身は単なる雑なメモなので、結論や主張はないです。 起こりうる問題 Elm で、サーバーがおかしな JSON を返してきた時にエラーが発生してアプリが止まることがある。一般的にはシステム境界でエラーが分かるのは嬉しいのだが、不寛容すぎると問題を起こしうる。 これは JavaScript とかだと起こらない問題で、 Elm とかだと起こりうる。例えば、{ name: string } みたいな API だとして {} が来た時に 「nameがない!」とエラーになる可能性がある。これを デコードエラー と呼ぶ。それが番で運用した時に問題にならないか、という話。確率は低そうだが考えておいて損はなさそう。 Elm 以外も含めて言語別に見ると、 JS の場合、プロパティが null や undefined でも構わず処理を続け、運悪く当たるとぬるぽになる。型が違った場合は適当に処理される

    Elm で不正な JSON に厳しすぎる問題についてのメモ - ジンジャー研究室
  • 正規表現ばかりに頼ってはいけない - id:anatooのブログ

    文字列のパースをする必要がある時、どんな文字列にでも何でもかんでも正規表現で処理しようとするエンジニアをたまに見かける。 正規表現は確かに文字列を扱うための強力な手段だが、万能ではない。正規表現の性質上、そもそもパースできない文法があるからだ。従ってそういうケースの時には正規表現ではなく別の方法を使ったほうが良い。正規表現を無理やり使っても、バグを埋め込んだり、メンテナンスが難しかったり、正しく文字列をパース出来なかったりで良いことはあまりない。 正規表現がパースできない文字列 正規表現が苦手とする文法で一番よく言われるのは、再帰的な構文を含む文法である。例えば、括弧つきの数式なんかがそうで、1+1 でも (1+1) でも ( (1+1) ) でも ( ( (1+1) ) ) でも ( ( ( ( 1+1) ) ) ) でも、という風にいくらでも入れ子にできる。正規表現では、こういった文字

    正規表現ばかりに頼ってはいけない - id:anatooのブログ
  • 1