JavaScript関連のことを調べてみた2023年08月09日

JavaScript関連のことを調べてみた2023年08月09日

[Gather.town]Denoでチャット内にオウム返しBOTを作成

– リモートコミュニケーションツールとして[Gather](https://gather.town/)を利用しています。
– Gatherは基本機能以外の仕掛けが沢山あり、その中の1つに[Socket API](http://gather-game-client-docs.s3-website-us-west-2.amazonaws.com/classes/Game.html)があり、プログラムでGather上の操作が可能です。
– 今回はそちらと[Deno](https://deno.com/)を利用してGatherのチャット内に簡単なBOTを実装する方法を記録いたします。

## 結果
– 成果物として、以下のようにチャット内でオウム返しするBOTを実装します。

![gather-chat.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/336499/332c01d8-c71c-97a5-b002-41c7bb6ed2e1.png)

## 環境
– macOS 13.0
– deno 1.36.0

元記事を表示

NeosVR コンパイラ その2

# 概要
NeosVRのオブジェクトを外部で生成するコンパイラを開発した。
俺コードから、生成します。

# 俺コード仕様

– new
コンポーネントを生成します。

new FrooxEngine.StaticTexture2D

コンポーネントStaticTexture2Dを生成

– 代入
プロパティを設定します。

FrooxEngine.StaticTexture2D.URL.Data = “https://apod.nasa.gov/apod/image/2308/GianniTumino_Moon_Rays_JPG_LOGO_1024pix.jpg”

urlを設定

– add
オブジェクトに、追加します。

add FrooxEngine.MeshRenderer
コンポーネントMeshRendererを追加します。

# サンプル1

画像を取得して、テクスチャーにして、四角に貼り付け、描画します。

“`
new FrooxEngine.StaticTexture2D
new FrooxEngine.UnlitMaterial
new FrooxEngi

元記事を表示

Svelteはじめました ? | SvelteKit | Cloudflare Workers

この抜粋の内容は次のとおりです。
– 環境構築
– Svelte
– SvelteKit
– Cloudflare

さらに詳しく知りたい方は読み続けてください。

2023年8月2回目です。

[Svelte](https://svelte.jp/) についてです。

身近の Frontend Engineer と Architect の間にある海溝。
それは、「やりたくない海溝⚡️」です。

やりたくない派の彼らの話を要約すると以下のとおりです。
– React で「状態管理」をやりたくない
– React で認証をやりたくない
– React で Rendering をやりたくない

そうですよね。どれも面倒です。そこに海溝がある。

「どいつもくだらないや からが人生」

その海溝を乗り越えませんか?

それが、Svelte です。もしくは、[Remix](https://remix.run/)。

SvelteKit で SSR をやっていきます。

## 環境構築
– 構成
– devcontainer
– Node.js + JavaScrip

元記事を表示

NeosVR コンパイラ

# 概要

NeosVRのオブジェクトを外部で生成するコンパイラを開発した。
NeosVRのユーザーの皆さんには、破綻していないことを実証願いたい。

# 実行確認の手順。
– 環境は、windows10
– NeosVRは、Streemじゃない方
– 以下のページで生成されたjsonを、メモ帳で「nasa.json」で保存する。

https://embed.plnkr.co/plunk/ZVGGbqmF14ZT5z0r

– NeosVRを起動して、セッションに入る。
– ファイルブラウザを開いて、「nasa.json」をダブルクリックする。
– 以下の画像が表示されれば、成功です。

![2023-08-09 00.00.42.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/e2648119-ff87-1969-7a1e-2eb9887eeeea.jpeg)

以上。

元記事を表示

async/awaitにおけるエラー処理を実行の順番から整理する

## はじめに
promiseを使うとき、いつもpromiseメソッドチェーンで記載していますか? async/awaitを利用していますか?
もちろん状況によって両方書くのが殆どだとは思うのですが、私はasync/awaitの方が同期的な書き方ゆえに読みやすいため、なるべくそちらで記載しています。しかしながら、エラーハンドリングが理解できていなかったため、エラーの所在を突き止めるのに苦労してしまいました。
そのため、これを機にasync/awaitにおけるエラーハンドリングについて備忘録的にまとめておきます。

## この記事のまとめ;
* catchされるエラーはrejectのみか、throwされたエラーも含まれるか
→両方catchできる
* async関数における処理の順序、awaitがある場合とない場合
→awaitがない場合には同期的に処理が実行され、catchできなくなる
* エラー処理を外側に伝播していく方法
→asyncのtry/catchで繋げられる

## catchされるエラーはrejectのみか、throwされたエラーも含まれるか
### そもそも、catch

元記事を表示

2つの配列の①重複要素のみの配列生成、②ユニーク要素のみとなる配列生成関数(文字列配列Ver.、オブジェクト配列Ver.)

# 経緯
JSで2つの配列を比較する際に、単純な文字列のみの配列同士であれば比較的簡単だったが、オブジェクトが入っている配列だった場合にちょっとだけ難しかったのでその備忘録です。

## 1.文字列で構成されている配列2つでチェック
前提条件 (1.1と1.2で共通の条件)
“`javascript:比較する配列
const arrayA = [“nick”, “bob”, “nancy”];
const arrayB = [“nick”, “michel”, “denny”, “bob”];
“`
### 1.1 重複要素のみを取得

“`javascript:2つの配列に重複している要素のみの配列取得
// 重複した内容のみの配列を生成
const getDuplicateArray = (orgArr1, orgArr2) => {
// 重複があるか判定したい配列を結合させる
const margeArray = […orgArr1, …orgArr2];

// 両配列に含まれているものなのかをincludesで判定
const

元記事を表示

DiscordのWebhookでNotionのURLがうまく表示されない件の対応メモ

こんな感じの通知を送りたいなと思った時にWebhookで送信するとうまくいかなかったという話です。

– 理想
> ![スクリーンショット 2023-08-05 17.38.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35387/9d58ea17-69ef-53fd-b189-ef7b5fc3c880.png “スクリーンショット 2023-08-05 17.38.34.png”)

– 現実
> ![スクリーンショット 2023-08-08 23.29.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35387/6225e0f6-ed7b-42da-1840-20785c086c00.png “スクリーンショット 2023-08-08 23.29.57.png”)

こんな感じでURLがうまく表示されません。

表示されないだけでなくクリックしても無効なリンクになってしまっています。

## Notion

元記事を表示

見通しを改善!Vue.js でのバリデーション処理のリファクタリング

# 課題

フロントエンド開発において、フォームのバリデーションと入力欄の管理は一般的な作業です。
特に、多くの入力欄を持つフォームでは、コードが複雑になり、メンテナンスが困難になることがあります。

今回の課題は、複雑なフォームのコードをリファクタリングして、より管理しやすく、再利用可能なコードにすることです。

元々のコードは機能していましたが、見通しの悪さが目立ち、特にスキーマの部分とuseFieldの部分で同じ名称が度々出てくること、そしてuseFieldを何行も書かなければならない点が問題でした。

# 考えた方法

この課題に対処するために、以下の方法を考えました。

1. useFieldの部分をスキーマ定義を使って簡略化する。
1. 共通の処理を外部に定義して、どのページでも使えるようにする。
1. スキーマ設定を外部ファイルに定義する。

# 前提条件
まず最初に今回リファクタリング対象となっているコードや環境について記述しておきます。

## リファクタリングするコード
“`javascript