@imo
s/
setCount(prevCount) => prevCount + 1 / setCount((prevCount) => prevCount + 1) setCount(count) は直前のcountを受け取るのではなく、countを新しい値で更新する関数です直前の値を受け取って新しい値に書き換えるのは
setCount((prevCount) => newCount) のほうあ、そういうことなのですね。感謝します！🙇♂️
スミマセン～、確認なのですが、
a.プリミティブな値を受け取ると、その値で更新する
a.jsx/** @jsx h */
/** @jsxFrag Fragment */
import { Fragment, h, render } from "https://esm.sh/preact@10.6.4";
import { useState, useCallback } from "https://esm.sh/preact@10.6.4/hooks";
const App = () => {
const [count, setCount] = useState(0);
const countUp = useCallback(() => setCount(count + 1), [count]);
const countDown = useCallback(() => setCount(count - 1), [count]);
return (
<div style="position: fixed; top:60px; left: 50%; transform: translate(-50%, 0); background-color: var(--page-bg, #fefefe); border: solid 1px rgba(0,0,0,.15); border-radius: 4px;">
Counter: {count}<br />
<span style="user-select: none;" onClick={countUp}>+</span>
<span style="user-select: none;" onClick={countDown}>-</span>
</div>
);
};
const div = document.createElement("div");
document.body.append(div);
render(<App />, div);
b.関数を受け取ると、その関数は直前の値を引数として受け取り、更新した値を返す
b.jsx/** @jsx h */
/** @jsxFrag Fragment */
import { Fragment, h, render } from "https://esm.sh/preact@10.6.4";
import { useState } from "https://esm.sh/preact@10.6.4/hooks";
const App = () => {
const [count, setCount] = useState(0);
const countUp = useCallback(() => setCount((prev) => prev + 1), []);
const countDown = useCallback(() => setCount((prev) => prev - 1), []);
return (
<div style="position: fixed; top:60px; left: 50%; transform: translate(-50%, 0); background-color: var(--page-bg, #fefefe); border: solid 1px rgba(0,0,0,.15); border-radius: 4px;">
Counter: {count}<br />
<span style="user-select: none;" onClick={countUp}>+</span>
<span style="user-select: none;" onClick={countDown}>-</span>
</div>
);
};
const div = document.createElement("div");
document.body.append(div);
render(<App />, div);
ということで合ってますか？
はい。あってます
折角なのでサンプルコード添えました
リンクを踏んで生成したコードを開発コンソールで実行すると試せます
なんと！お時間割いていただき感謝します🙏
setCount((prevCount) => newCount) の形があるのは、再レンダリングの抑制のためですたとえば以下の場合、
useEffect 部分が無限ループに陥ってしまう setState で state を更新する→ state の値が変わるので次のレンダリングサイクルで useEffect が再実行される→再び state の更新が走る→ useEffect が再実行→ state が更新される→(以下無限ループ)jsconst [state, setState] = useState(0);
useEffect(() => {
// ...
const newState = state + 1;
setState(newState);
// ...
}, [state, /* ... */]);関数形の更新方法を用いると、このような「前の状態を使いたいけど、再レンダリングの対象にしたくない」場合に対応できる
jsconst [state, setState] = useState(0);
useEffect(() => {
// ...
setState((prevState) => prevState + 1);
// ...
}, [/* ... */]); // 依存配列からstateを消せる
useEffect は、第一引数にコールバック関数を、第二引数に変更を見たい値を配列に入れて取る、という感じで合ってますか？で、前者のコードはコールバック内で変更される値を第二引数に取ってるからループする、という
そういうことです
ワガママで恐縮なのですが、後者のコードが使われる状況が想像しづらかったので、この形が実際に使われている例などは見せて頂けませんでしょうか？
わかりました～。UserScriptでよく使っているのですぐ出てきそうです
と思ったが意外とすぐに見つからない
useMemo() ばっかだどうやらコールバックを使うパターンは少なそうです
複雑なコードで申し訳ないですが、見つかったのを載せておきます
値Aの更新を引き金に、値Aと値Bから新しい値Bを作成するロジックで使われているみたいです
大抵は値Aから値Bを作成するロジックですむので、使用頻度は少ないのかも
コールバック系のsetStateの出現率をコードの複雑さの指標として使えるかもしれない
感謝します！🙏時間をかけて読んでみようと思います
実例をすぐに見せていただけることはありがたいことでございます🙇♂️
画像を見て、imo さんを連想したのでご報告
これは可愛い！買います
画像見てフイタw
これか！
自分が書いたわけではなかった
目標と過程の話を読んで、似たようなことを書かれている記事↓を思い出しました
読んでみるといいかもです
謝謝🙏
記載してませんでしたが、自分の記事はkidooomさんのページを読んで書いたものでした🙇♂️
会社に入ると「目標設定」で多くの人が悩んでて、結構な時間を使ってました（自分もそう）
リンクを色々眺めてみたんですが、これに似たことが結構詳細に書かれていますね
図示されてて良いですね。図を見て、スクウェア・エニックスのCTOの方が書いたこの資料を思い出しました。
お～分かりやすいです
そしてこういう状況になるとめっちゃヘコむ…
失敗プロジェクトを「計画なしで進めた社会基盤施設の設計施工運用」と同類としてみると、途端に恐ろしさを実感できる
ブレイドとファイズだー！！
マジでキングフォーム好きなんですよねー、カブトムシのツノを王冠にしているのがデザイン的に完璧すぎる
メカっぽいと言えば、G3-Xやイクサ、バース、魔進チェイサーも参考になりそうです
あーバース良いですね、個人的にあれくらいのディティール密度が好きだったり
あとはダブルのSJエクストリームも良さそう
「メカ + 西洋っぽい鎧」の組み合わせでULTRAMAN版のアグルスーツを基にしようと思っていたのですが、仮面ライダーの方からもいくつか参考にしようと思って色々探してましたｗ
うわああああああ
恐縮です…ありがとうございます！！
こんなの初めてです〜嬉しい
👍
喜んでもらえるの嬉しいですね～
めっちゃスタイリッシュなちゃんみおだ！
そもそも今自分の前にあるそれが問題なのかどうかから考えるという視点もありそうですね
問題でなければ、問題解決のプロセスを進める必要もないわけで
ですね、そもそも「問題の発見→即座にその解決」というやり方は場合によって裏目に出たりする
一見して問題でも全体で見ると他の要素との依存関係が出来ていたり
そういうことなのでそれが問題なのかということの他、問題だったとしても解決せずに放置・保留することが案外ベストだったりする
その他このあたりも、1個は自分のページなので若干恥ずかしいですが…
コストの観点には気づきませんでした
教科書をそのまま写せば予習として認められるのに、専門用語の英訳や、数式の厳密な定義を調べ始めて余計な時間を食うのと同じ構図かな？
ちょっと違う気がする
あとこれは自分の話になってしまうので恐縮ですが、自分は「ポジティブに言い換える」の代わりに/takker/道具として駆使するという語句を使っています
例えば器用貧乏であれグズであれ、良いか悪いか云々以前にただの事実なんですよね
(事実を誤認してる場合もある)
レベルの高い周囲との比較で自分を過小評価してしまう、みたいな場合も考えられますね
あるあるです
ハードル高くして自滅するパターン
いままあ自分のことなんですけどね
少しずつ修正しているつもり
わかる、もっと言うと、それは評価者の主観でもあるわけだし、それ以上の意味合いは含まないはず
しかし主観に基づく評価によって気分が左右されるということもまた事実…なのでそのあたりの気分の整え方は心得ておきたい
これに関連したことがどこかに書いてあった気がするような……
思い出したら貼りますね
それを受けて自分がどう反応するかは自由です
ならば、それを手持ちのカードだとみなして、他のカードと組み合わせて何を為すのかを考えればいいわけです
もちろん、カード自体を強化したり(自己研鑽)、逆の性質を持つカードに変えたり(弱点とみなして克服)するという手段もとれます
ただ、それらが一番優先される手段ではなく、他の無数にある手段の一つとして相対化されているのが重要なんじゃないかと思っています
デスネ、どうにも問題（に、見えるもの）が目の前にあると取り掛かりたくなるということはある…
まあ大抵は対象を問題だと認識して解決する手段しかとれないことが往々にしてあるけど
また一応、該当ページを書いた文脈として、「なんか最近ネガティブな性質をポジティブに言い換えるライフハックを見るな～」みたいなことを感じていたというものがあります
それ自体は大いにアリだとは思うのですが、そのライフハックに「ネガティブな性質は存在してはいけない」みたいな前提を感じてなんだかな～とも思っていました（これは邪推だと思います、提案している人は励ましのつもりだろうし）
何をやっても中途半端な人とか、要領の悪い人とか、それらを無理にポジティブに置き換えようとせず、それはそのままとして存在し続けても別に良くね…とは思います
ぜんぶわかる
また個人的な意見ですが、人間のデフォルトは悲観主義で、楽観主義の方が作られた状態だと思うので、ポジティブなスタンスはエネルギーに余裕があるときにやるのが望ましいかなとも思います
ただまあ、人を元気づけようとして、裏目としてポジティブを強要するようなダル絡みになってしまうことは、割と私自身に心当たりがあり…
他者を元気づけるのはとても難しいと思います
なるほどたしかに
2021/05/09#6097aac61280f000001bdf1aのようなケースを考えると、デフォルトは存在せず、その時その時で主義が変わるんじゃないかと思いましたが、「学問する」を外部から与えられたpotentialだとみなせば、確かに楽観主義は作られたものかもしれませんね
もちろん、深くつっこめば単純な二分法に帰着できないのは自明ですが、大まかなイメージとしては問題ないと思います
悲観・楽観の分け方は雑な二分法ですねｗ汲み取ってもらってスミマセン
もしかしたらデフォルトで楽観主義の人もいるかも？
質問される前に回答するという高度な技をやろうかと思いましたが、さん自身で調べたさそうなので控えておきます
参考になりそうな情報源だけ上げておきます
関連する概念
pythonのtuple
ここまで文献上げたらもう回答したようなものな気がするけどまあいいや
あら！これは非常に嬉しい
ちょっと読んだのですが、この書き方をするメリットが、1.後で書くときに簡易に出来ること、2.引数を渡す際の順番を考慮しなくてよくなること、ってことですか？
1.
user側の利点は場合によっては薄くなるかもです
test(0) と書けば済むはずが、わざわざ test({index: 0}) と書かなくてはいけなくなる名前付き引数のデメリットです
また開発者側からすると
jsfunction test({title, project}) {
//...
}と書くか、
jsfunction text(params) {
const {title, project} = params;
//...
}と書くかの違いなので、見方を変えるとそこまでのメリットでもないんですよね
2. これが一番大きいですね
ちなみに型付き言語なら、型である程度順番間違えを防げます
e.g.
function test(value1: string, value2: number) を test(0, 'test') と呼び出すとType Errorになる尤も引数がどれも同じ型だったりすると防ぎようがないので、あくまである程度ですね
e.g.
function test(value1: string, value2: string) は test('foo', 'bar') で呼び出しても test('bar', 'foo') で呼び出してもエラーにならないなるほど
例えば
function test(param) ではなく function test({param}) のような書き方は、あとでその引数に値を入れるときに便利になり、で、
const greet = ({ name, msg = 'Hi' } = {}) => みたいな形をとるのは、ここで言えばnameと msg の値に "Hi" をデフォルトとして指定するための書き方ってことですか？といっても、これらは今の私みたいに初めたての段階だと、肌感覚であまりメリットを感じられない感じもしますがっ！
そんな感じです
あ、カンマ区切りは複数指定ではないわけですね
また質問したかったことについてなんですが、以前takkerさんが作ったUserScriptに
import 文が使われていたことと、それについての注意事項について以下に書かれていたので、 import を使わない書き方のものにしてみたかったんですよね（takkerさんやyosiderさん達を疑っているわけじゃないですヨ）
大事な心がけと思います
おっしゃるとおりです。本当はこの部分も
import を使わないか、 /api/code/nota-techconf からのimportに留めるべきですそれをせず別のprojectからimportした理由は、単に同じコードを書くのが面倒くさかったからですごめんなさい……
全然大丈夫ですよ～！ｗ
で、コードのどの部分が使われているかを確認しながら書き換えることは勉強にもなるかな～と思って調べていたという感じです
takkerさんに直接答えを聞いた方が早いのは間違いないのですが、まあちょっと勉強も兼ねてやりたいので、自分ではお手上げの状態になったらまた伺っても良いですか？
いつでも大丈夫ですよ～
といっても別にprogrammingは専業じゃないので、あまり教えられることはないと思います。それでもよろしければお答えします。
ありがたし
importを使うこと自体が危ないというより、他人が編集できるUserScriptをimportすることが危ないので、importを使わないのではなく、import先のUserScriptも含めて個人プロジェクトにコピーして、個人プロジェクト内でimportするのがいいかなと思います
これについてなんですが、import元になっているスクリプトがどういう関係になっているかが自分には複雑で理解できていなかったんですねｗ
script.jsimport {press} from '/api/code/programming-notes/scrapbox-keyboard-emulation/script.js';
import {goHeadLine} from '/api/code/takker/scrapbox-cursor-emulation/cursor.js';
let repeat = false;
// 以下略ここの1、2行目でimportされてるコードが、どういうもの・どういう意図でimportされてるのかな～というのを理解したかった
import 文に説明つけたほうが良いかなあでも/programming-notes/scrapbox-keyboard-emulationと/takker/scrapbox-cursor-emulationに飛べばなんのコードか分かるので、説明をつける必要はあまりなさそう
（勝手にアドバイスしてしまいすみません）
や！全然ありがたいです！