編集履歴

回答編集履歴

テキスト修正

2018/09/24 12:06

投稿

スコア9058

test CHANGED Viewed

@@ -202,7 +202,7 @@
-なるほどですね。おそらくこのコードは、
+なるほどですね。おそらく [このコード](https://jsfiddle.net/psn5849w/97/) は、

テキスト修正

2018/09/24 12:06

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -80,7 +80,7 @@
 こんにちは。
-だいぶ時間が経ってしまいましたが、その後も機能追加などを行っているようですね。
+だいぶ時間が経ってしまいましたが、その後も機能追加などの作業が続いていらっしゃるご様子ですね。

テキスト修正

2018/09/24 12:03

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -224,11 +224,11 @@
-つまり、分かり易くいえば、もし仮に、私と貴殿が同じ職場で働く同僚であったならば、
+__つまり、分かり易くいえば、もし仮に、私と貴殿が同じ職場で働く同僚であったならば、__
-「ほらみろｗ だから、【パターン：あ】　は辞めとけっていったのに〜ｗ」
+__「ほらみろｗ だから、【パターン：あ】　は辞めとけっていったのに〜ｗ」__
-と、（心の中で、そっと） disるだろうなあということですね。
+__と、（心の中で、そっと） disるかもしれないなあ、ということですね。__

テキスト修正

2018/09/24 11:52

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -256,8 +256,24 @@
-- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、**ツリーを保持したデータ構造によって、** 持っておくほうがよいのでは？と思います。
+- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、**ツリーを保持したデータ構造によって、** 持っておくほうがよいのでは？と（無責任な思いつきですが、）思ったりもします。
 - たとえば、でいうと、返信ふくめた投稿のツリー情報を XMLで返すAPIをバックエンドで用意しておき、フロントエンドでこれを呼んだレスポンスをパースした結果を親子関係のマスターデータとし、これに対して JQuery のセレクタを使って投稿の親子関係を取得して、画面HTMLのDOMに反映させる、みたいなことですね。
+---
+**追伸3**
+いずれにせよ、ここから先は、バックエンドの投稿テーブルの作り方だったり、サーバーサイドでどこまで画面がレンダリングされてきて、どこから先をフロントエンドでやるのか？ みたいな詳細に突っ込まないと正確なコメントはできなさそうです。
+頑張ってください！

テキスト修正

2018/09/24 11:12

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -256,7 +256,7 @@
-- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって、）持っておくほうがよいのでは？と思います。
+- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、**ツリーを保持したデータ構造によって、** 持っておくほうがよいのでは？と思います。

テキスト修正

2018/09/24 11:00

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -252,7 +252,7 @@
-- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するに留めておき、画面表示上は「この投稿は削除されました」という表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。
+- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するだけに留めておき、画面表示上は「この投稿は削除されました」といった感じで表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。

テキスト修正

2018/09/24 10:58

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -102,7 +102,7 @@
-を拝見して、どのようなロジックで動いているかもだいたい把握しました。その上で指摘させて頂きたい点は以下です。（1)と（２）は細かいツッコミですが、 (3)はこのままだと不具合が起こる点の指摘です。
+を拝見して、どのようなロジックで動いているかもだいたい把握しました。その上で指摘させて頂きたい点は以下です。（1)と（２）は細かいツッコミですが、 (3)はこのままだと不具合が起こる気がする点です。

テキスト修正

2018/09/24 10:55

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -256,4 +256,8 @@
-- それと、【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると大変なので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって）持っておくほうがよいのでは？と思います。
+- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって、）持っておくほうがよいのでは？と思います。
+- たとえば、でいうと、返信ふくめた投稿のツリー情報を XMLで返すAPIをバックエンドで用意しておき、フロントエンドでこれを呼んだレスポンスをパースした結果を親子関係のマスターデータとし、これに対して JQuery のセレクタを使って投稿の親子関係を取得して、画面HTMLのDOMに反映させる、みたいなことですね。

テキスト修正

2018/09/24 10:54

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -210,7 +210,7 @@
-とあったとおり、力作ではあるのでしょうから、なんとかしたいお気持ちも分かります。しかし、ある投稿（post)が削除される可能性があり、これに対応しようとするとエラーになってしまったという状況は、私からすると、元の回答に書いた、【パターン：あ】を使うことへの所感：
+とあったとおり、力作ではあるのでしょうから、なんとかしたいお気持ちも分かります。しかし、ある投稿（post)が削除される可能性があり、これに対応しようとするとエラーになってしまったという状況は、私からすると、2018/09/01 01:22　のコメントに書いた、【パターン：あ】を使うことへの所感：

テキスト修正

2018/09/24 10:38

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -232,7 +232,7 @@
-ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動などは、プログラミングの勉強にはなりますし、自分で書くとアルゴリズムの勉強になりますし楽しかったりもするのでハマる気持ちも分かりますが、これがもし何らかの製品として本番サーバーに載せるサービスの一部であるなら、こういうツリー操作はまさにDOM操作のお家芸ですから、先達のプログラマーの成果に乗っかった方が良い気がします。（つまり、【パターン：い】を採用するということですね。）
+ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動などを自分で書くとアルゴリズムの勉強になりますし楽しかったりもするのでハマる気持ちも分かりますが、これがもし何らかの製品として本番サーバーに載せるサービスの一部であるなら、こういうツリー操作はまさにDOM操作のお家芸ですから、先達のプログラマーの成果に乗っかった方が良い気がします。（つまり、投稿の親子関係をDOMの親子関係に乗せた【パターン：い】を採用するということですね。）

テキスト修正

2018/09/24 10:36

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -241,3 +241,19 @@
 とはいえ、明らかに大変なのに、【パターン：あ】に猪突猛進した貴殿の勢い、嫌いではありません。
+---
+**追伸2**
+- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するに留めておき、画面表示上は「この投稿は削除されました」という表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。
+- それと、【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると大変なので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって）持っておくほうがよいのでは？と思います。

テキスト修正

2018/09/24 10:29

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -110,7 +110,7 @@
-  `<ul class="children">` の `childrens` は、末尾の s が不要なので削除し `children` とする。
+  `<ul class="childrens">` の `childrens` は、末尾の s が不要なので削除し `children` とする。

テキスト修正

2018/09/24 09:39

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -228,7 +228,7 @@
 「ほらみろｗ だから、【パターン：あ】　は辞めとけっていったのに〜ｗ」
-と、ここぞとばかりにdisるだろうなあということですね。
+と、（心の中で、そっと） disるだろうなあということですね。

テキスト修正

2018/09/24 09:30

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -69,3 +69,175 @@
 以上、参考になれば幸いです。
+---
+**追伸**
+こんにちは。
+だいぶ時間が経ってしまいましたが、その後も機能追加などを行っているようですね。
+さて、次の 1. と 2.  について回答します。
+1. コードに対する指摘点
+2. getParentNums が再帰を使っていることで起こるエラーについて
+### 1. コードに対する指摘点
+https://jsfiddle.net/psn5849w/97/
+を拝見して、どのようなロジックで動いているかもだいたい把握しました。その上で指摘させて頂きたい点は以下です。（1)と（２）は細かいツッコミですが、 (3)はこのままだと不具合が起こる点の指摘です。
+#### (1) childrens の末尾の s が不要
+  `<ul class="children">` の `childrens` は、末尾の s が不要なので削除し `children` とする。
+#### (2) 配列.indexOf(x) >= 0 の替わりに、配列.includes(x) を使う
+配列に何か特定の要素が含まれるかの判定には、 indexOf ではなく、 [includes](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/includes) を使う。
+　修正前：
+```javascript
+if (parents.indexOf(my_post_num) >= 0){
+```
+　修正後：
+```javascript
+if (parents.includes(my_post_num)){
+```
+#### (3) 正規表現の修正
+closeがクリックされたときの閉じる子要素の判定に使う正規表現の修正
+　修正前：
+```javascript
+var child_ancestor_num = click_ancestor_num+'-'+click_post_num;
+```
+　修正後：
+```javascript
+var child_ancestor_num_pattern = new RegExp(`^${click_ancestor_num}-${click_post_num}(-\d+)*$`);
+```
+　　　　　として、以下のようにチェックする。
+```javascript
+if (ancestor_num.match(child_ancestor_num_pattern)){
+```
+修正前だと、もし `child_ancestor_num` がたとえば　`"0-111-222"` で、 `ancestor_num` が `"0-10-111-2229-76"`のとき、以下の判定
+```javascript
+"0-10-111-2229-76".match("0-111-222");
+```
+はマッチしてしまうので意図しない動作を引き起こす原因になります。修正後のように正規表現を作ることでこれを避けられます。
+### 2. getParentNums が再帰を使っていることで起こるエラーについて
+> コメントが削除された場合、再帰になっているせいで「親が削除されて見つからない」→「too much recursionエラー！」になってしまうのです。
+なるほどですね。おそらくこのコードは、
+> 教えて頂いたり拾ったりしたコードを一晩中切って貼ってを繰り返した
+とあったとおり、力作ではあるのでしょうから、なんとかしたいお気持ちも分かります。しかし、ある投稿（post)が削除される可能性があり、これに対応しようとするとエラーになってしまったという状況は、私からすると、元の回答に書いた、【パターン：あ】を使うことへの所感：
+> ・・・・・ 直感として思うのは、
+> 「慎重に書かないとバグのあるコードを書いてしまいそう」
+に当てはまる事態であったりします。
+つまり、分かり易くいえば、もし仮に、私と貴殿が同じ職場で働く同僚であったならば、
+「ほらみろｗ だから、【パターン：あ】　は辞めとけっていったのに〜ｗ」
+と、ここぞとばかりにdisるだろうなあということですね。
+ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動などは、プログラミングの勉強にはなりますし、自分で書くとアルゴリズムの勉強になりますし楽しかったりもするのでハマる気持ちも分かりますが、これがもし何らかの製品として本番サーバーに載せるサービスの一部であるなら、こういうツリー操作はまさにDOM操作のお家芸ですから、先達のプログラマーの成果に乗っかった方が良い気がします。（つまり、【パターン：い】を採用するということですね。）
+さらにより賢明なのは、ツリーの基礎となるグラフ理論の初歩をかじったり、ツリーのノードを一番上から下へ、あるいは、末端のノードから上へ再帰でたどるコードを自分で書いたり、他の人のコードを読んだりして、「やろうと思えば自分で書ける」と思えるだけのプログラミング力はキープしつつ、明らかに先達の作ったコードに乗っかった方がよいときは思いっきり乗っかって楽をして、自分はもっと別の重要なコードを書く方に時間をあてる、みたいな姿勢かなと思います。
+とはいえ、明らかに大変なのに、【パターン：あ】に猪突猛進した貴殿の勢い、嫌いではありません。

テキスト修正

2018/09/24 09:22

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -2,7 +2,7 @@
-以下のように修正すると、いかがでしょうか？
+以下のように`if`条件を修正すると、いかがでしょうか？