回答編集履歴
15
テキスト修正
answer
CHANGED
|
@@ -100,7 +100,7 @@
|
|
|
100
100
|
|
|
101
101
|
> コメントが削除された場合、再帰になっているせいで「親が削除されて見つからない」→「too much recursionエラー！」になってしまうのです。
|
|
102
102
|
|
|
103
|
-
なるほどですね。おそらくこのコードは、
|
|
103
|
+
なるほどですね。おそらく [このコード](https://jsfiddle.net/psn5849w/97/) は、
|
|
104
104
|
|
|
105
105
|
> 教えて頂いたり拾ったりしたコードを一晩中切って貼ってを繰り返した
|
|
106
106
|
|
14
テキスト修正
answer
CHANGED
|
@@ -39,7 +39,7 @@
|
|
|
39
39
|
**追伸**
|
|
40
40
|
|
|
41
41
|
こんにちは。
|
|
42
|
-
だいぶ時間が経ってしまいましたが、その後も機能追加など
|
|
42
|
+
だいぶ時間が経ってしまいましたが、その後も機能追加などの作業が続いていらっしゃるご様子ですね。
|
|
43
43
|
|
|
44
44
|
さて、次の 1. と 2. について回答します。
|
|
45
45
|
|
13
テキスト修正
answer
CHANGED
|
@@ -111,9 +111,9 @@
|
|
|
111
111
|
|
|
112
112
|
に当てはまる事態であったりします。
|
|
113
113
|
|
|
114
|
-
つまり、分かり易くいえば、もし仮に、私と貴殿が同じ職場で働く同僚であったならば、
|
|
114
|
+
__つまり、分かり易くいえば、もし仮に、私と貴殿が同じ職場で働く同僚であったならば、__
|
|
115
|
-
「ほらみろｗ だから、【パターン：あ】 は辞めとけっていったのに〜ｗ」
|
|
115
|
+
__「ほらみろｗ だから、【パターン：あ】 は辞めとけっていったのに〜ｗ」__
|
|
116
|
-
と、（心の中で、そっと） disる
|
|
116
|
+
__と、（心の中で、そっと） disるかもしれないなあ、ということですね。__
|
|
117
117
|
|
|
118
118
|
ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動などを自分で書くとアルゴリズムの勉強になりますし楽しかったりもするのでハマる気持ちも分かりますが、これがもし何らかの製品として本番サーバーに載せるサービスの一部であるなら、こういうツリー操作はまさにDOM操作のお家芸ですから、先達のプログラマーの成果に乗っかった方が良い気がします。（つまり、投稿の親子関係をDOMの親子関係に乗せた【パターン：い】を採用するということですね。）
|
|
119
119
|
|
12
テキスト修正
answer
CHANGED
|
@@ -127,6 +127,14 @@
|
|
|
127
127
|
|
|
128
128
|
- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するだけに留めておき、画面表示上は「この投稿は削除されました」といった感じで表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。
|
|
129
129
|
|
|
130
|
-
- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、**ツリーを保持したデータ構造によって、** 持っておくほうがよいのでは？と思います。
|
|
130
|
+
- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、**ツリーを保持したデータ構造によって、** 持っておくほうがよいのでは？と（無責任な思いつきですが、）思ったりもします。
|
|
131
131
|
|
|
132
|
-
- たとえば、でいうと、返信ふくめた投稿のツリー情報を XMLで返すAPIをバックエンドで用意しておき、フロントエンドでこれを呼んだレスポンスをパースした結果を親子関係のマスターデータとし、これに対して JQuery のセレクタを使って投稿の親子関係を取得して、画面HTMLのDOMに反映させる、みたいなことですね。
|
|
132
|
+
- たとえば、でいうと、返信ふくめた投稿のツリー情報を XMLで返すAPIをバックエンドで用意しておき、フロントエンドでこれを呼んだレスポンスをパースした結果を親子関係のマスターデータとし、これに対して JQuery のセレクタを使って投稿の親子関係を取得して、画面HTMLのDOMに反映させる、みたいなことですね。
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
**追伸3**
|
|
137
|
+
|
|
138
|
+
いずれにせよ、ここから先は、バックエンドの投稿テーブルの作り方だったり、サーバーサイドでどこまで画面がレンダリングされてきて、どこから先をフロントエンドでやるのか？ みたいな詳細に突っ込まないと正確なコメントはできなさそうです。
|
|
139
|
+
|
|
140
|
+
頑張ってください！
|
11
テキスト修正
answer
CHANGED
|
@@ -127,6 +127,6 @@
|
|
|
127
127
|
|
|
128
128
|
- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するだけに留めておき、画面表示上は「この投稿は削除されました」といった感じで表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。
|
|
129
129
|
|
|
130
|
-
- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、
|
|
130
|
+
- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、**ツリーを保持したデータ構造によって、** 持っておくほうがよいのでは？と思います。
|
|
131
131
|
|
|
132
132
|
- たとえば、でいうと、返信ふくめた投稿のツリー情報を XMLで返すAPIをバックエンドで用意しておき、フロントエンドでこれを呼んだレスポンスをパースした結果を親子関係のマスターデータとし、これに対して JQuery のセレクタを使って投稿の親子関係を取得して、画面HTMLのDOMに反映させる、みたいなことですね。
|
10
テキスト修正
answer
CHANGED
|
@@ -125,7 +125,7 @@
|
|
|
125
125
|
|
|
126
126
|
**追伸2**
|
|
127
127
|
|
|
128
|
-
- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するに留めておき、画面表示上は「この投稿は削除されました」とい
|
|
128
|
+
- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するだけに留めておき、画面表示上は「この投稿は削除されました」といった感じで表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。
|
|
129
129
|
|
|
130
130
|
- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって、）持っておくほうがよいのでは？と思います。
|
|
131
131
|
|
9
テキスト修正
answer
CHANGED
|
@@ -50,7 +50,7 @@
|
|
|
50
50
|
|
|
51
51
|
https://jsfiddle.net/psn5849w/97/
|
|
52
52
|
|
|
53
|
-
を拝見して、どのようなロジックで動いているかもだいたい把握しました。その上で指摘させて頂きたい点は以下です。（1)と（２）は細かいツッコミですが、 (3)はこのままだと不具合が起こる点
|
|
53
|
+
を拝見して、どのようなロジックで動いているかもだいたい把握しました。その上で指摘させて頂きたい点は以下です。（1)と（２）は細かいツッコミですが、 (3)はこのままだと不具合が起こる気がする点です。
|
|
54
54
|
|
|
55
55
|
#### (1) childrens の末尾の s が不要
|
|
56
56
|
|
8
テキスト修正
answer
CHANGED
|
@@ -127,4 +127,6 @@
|
|
|
127
127
|
|
|
128
128
|
- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するに留めておき、画面表示上は「この投稿は削除されました」という表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。
|
|
129
129
|
|
|
130
|
-
- それと、【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると大変なので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって）持っておくほうがよいのでは？と思います。
|
|
130
|
+
- それと、今後も 【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると何かと大変そうなので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって、）持っておくほうがよいのでは？と思います。
|
|
131
|
+
|
|
132
|
+
- たとえば、でいうと、返信ふくめた投稿のツリー情報を XMLで返すAPIをバックエンドで用意しておき、フロントエンドでこれを呼んだレスポンスをパースした結果を親子関係のマスターデータとし、これに対して JQuery のセレクタを使って投稿の親子関係を取得して、画面HTMLのDOMに反映させる、みたいなことですね。
|
7
テキスト修正
answer
CHANGED
|
@@ -104,7 +104,7 @@
|
|
|
104
104
|
|
|
105
105
|
> 教えて頂いたり拾ったりしたコードを一晩中切って貼ってを繰り返した
|
|
106
106
|
|
|
107
|
-
とあったとおり、力作ではあるのでしょうから、なんとかしたいお気持ちも分かります。しかし、ある投稿（post)が削除される可能性があり、これに対応しようとするとエラーになってしまったという状況は、私からすると、
|
|
107
|
+
とあったとおり、力作ではあるのでしょうから、なんとかしたいお気持ちも分かります。しかし、ある投稿（post)が削除される可能性があり、これに対応しようとするとエラーになってしまったという状況は、私からすると、2018/09/01 01:22 のコメントに書いた、【パターン：あ】を使うことへの所感：
|
|
108
108
|
|
|
109
109
|
> ・・・・・ 直感として思うのは、
|
|
110
110
|
> 「慎重に書かないとバグのあるコードを書いてしまいそう」
|
6
テキスト修正
answer
CHANGED
|
@@ -115,7 +115,7 @@
|
|
|
115
115
|
「ほらみろｗ だから、【パターン：あ】 は辞めとけっていったのに〜ｗ」
|
|
116
116
|
と、（心の中で、そっと） disるだろうなあということですね。
|
|
117
117
|
|
|
118
|
-
ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動など
|
|
118
|
+
ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動などを自分で書くとアルゴリズムの勉強になりますし楽しかったりもするのでハマる気持ちも分かりますが、これがもし何らかの製品として本番サーバーに載せるサービスの一部であるなら、こういうツリー操作はまさにDOM操作のお家芸ですから、先達のプログラマーの成果に乗っかった方が良い気がします。（つまり、投稿の親子関係をDOMの親子関係に乗せた【パターン：い】を採用するということですね。）
|
|
119
119
|
|
|
120
120
|
さらにより賢明なのは、ツリーの基礎となるグラフ理論の初歩をかじったり、ツリーのノードを一番上から下へ、あるいは、末端のノードから上へ再帰でたどるコードを自分で書いたり、他の人のコードを読んだりして、「やろうと思えば自分で書ける」と思えるだけのプログラミング力はキープしつつ、明らかに先達の作ったコードに乗っかった方がよいときは思いっきり乗っかって楽をして、自分はもっと別の重要なコードを書く方に時間をあてる、みたいな姿勢かなと思います。
|
|
121
121
|
|
5
テキスト修正
answer
CHANGED
|
@@ -119,4 +119,12 @@
|
|
|
119
119
|
|
|
120
120
|
さらにより賢明なのは、ツリーの基礎となるグラフ理論の初歩をかじったり、ツリーのノードを一番上から下へ、あるいは、末端のノードから上へ再帰でたどるコードを自分で書いたり、他の人のコードを読んだりして、「やろうと思えば自分で書ける」と思えるだけのプログラミング力はキープしつつ、明らかに先達の作ったコードに乗っかった方がよいときは思いっきり乗っかって楽をして、自分はもっと別の重要なコードを書く方に時間をあてる、みたいな姿勢かなと思います。
|
|
121
121
|
|
|
122
|
-
とはいえ、明らかに大変なのに、【パターン：あ】に猪突猛進した貴殿の勢い、嫌いではありません。
|
|
122
|
+
とはいえ、明らかに大変なのに、【パターン：あ】に猪突猛進した貴殿の勢い、嫌いではありません。
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
**追伸2**
|
|
127
|
+
|
|
128
|
+
- それでも、【パターン：い】でいくのであれば、ある投稿（post)が削除されたとしても、それは、バックエンドのデータベースの投稿テーブルでレコードを物理削除しないで論理削除するに留めておき、画面表示上は「この投稿は削除されました」という表示される投稿として、親子関係のツリーからは消えないようにするのが、ひとつ手としてあるかなと思います。
|
|
129
|
+
|
|
130
|
+
- それと、【パターン：い】でいくにしても、ツリーの情報をHTML要素の `my_ancestor_num` などの属性に、ハイフン区切りの文字列で持たせると大変なので、投稿ツリーをDOMとは別の場所に、（ツリーを保持したデータ構造によって）持っておくほうがよいのでは？と思います。
|
4
テキスト修正
answer
CHANGED
|
@@ -54,7 +54,7 @@
|
|
|
54
54
|
|
|
55
55
|
#### (1) childrens の末尾の s が不要
|
|
56
56
|
|
|
57
|
-
`<ul class="
|
|
57
|
+
`<ul class="childrens">` の `childrens` は、末尾の s が不要なので削除し `children` とする。
|
|
58
58
|
|
|
59
59
|
#### (2) 配列.indexOf(x) >= 0 の替わりに、配列.includes(x) を使う
|
|
60
60
|
|
3
テキスト修正
answer
CHANGED
|
@@ -113,7 +113,7 @@
|
|
|
113
113
|
|
|
114
114
|
つまり、分かり易くいえば、もし仮に、私と貴殿が同じ職場で働く同僚であったならば、
|
|
115
115
|
「ほらみろｗ だから、【パターン：あ】 は辞めとけっていったのに〜ｗ」
|
|
116
|
-
と、
|
|
116
|
+
と、（心の中で、そっと） disるだろうなあということですね。
|
|
117
117
|
|
|
118
118
|
ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動などは、プログラミングの勉強にはなりますし、自分で書くとアルゴリズムの勉強になりますし楽しかったりもするのでハマる気持ちも分かりますが、これがもし何らかの製品として本番サーバーに載せるサービスの一部であるなら、こういうツリー操作はまさにDOM操作のお家芸ですから、先達のプログラマーの成果に乗っかった方が良い気がします。（つまり、【パターン：い】を採用するということですね。）
|
|
119
119
|
|
2
テキスト修正
answer
CHANGED
|
@@ -33,4 +33,90 @@
|
|
|
33
33
|
>
|
|
34
34
|
```
|
|
35
35
|
|
|
36
|
-
以上、参考になれば幸いです。
|
|
36
|
+
以上、参考になれば幸いです。
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
**追伸**
|
|
40
|
+
|
|
41
|
+
こんにちは。
|
|
42
|
+
だいぶ時間が経ってしまいましたが、その後も機能追加などを行っているようですね。
|
|
43
|
+
|
|
44
|
+
さて、次の 1. と 2. について回答します。
|
|
45
|
+
|
|
46
|
+
1. コードに対する指摘点
|
|
47
|
+
2. getParentNums が再帰を使っていることで起こるエラーについて
|
|
48
|
+
|
|
49
|
+
### 1. コードに対する指摘点
|
|
50
|
+
|
|
51
|
+
https://jsfiddle.net/psn5849w/97/
|
|
52
|
+
|
|
53
|
+
を拝見して、どのようなロジックで動いているかもだいたい把握しました。その上で指摘させて頂きたい点は以下です。（1)と（２）は細かいツッコミですが、 (3)はこのままだと不具合が起こる点の指摘です。
|
|
54
|
+
|
|
55
|
+
#### (1) childrens の末尾の s が不要
|
|
56
|
+
|
|
57
|
+
`<ul class="children">` の `childrens` は、末尾の s が不要なので削除し `children` とする。
|
|
58
|
+
|
|
59
|
+
#### (2) 配列.indexOf(x) >= 0 の替わりに、配列.includes(x) を使う
|
|
60
|
+
|
|
61
|
+
配列に何か特定の要素が含まれるかの判定には、 indexOf ではなく、 [includes](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/includes) を使う。
|
|
62
|
+
|
|
63
|
+
修正前：
|
|
64
|
+
```javascript
|
|
65
|
+
if (parents.indexOf(my_post_num) >= 0){
|
|
66
|
+
```
|
|
67
|
+
修正後：
|
|
68
|
+
```javascript
|
|
69
|
+
if (parents.includes(my_post_num)){
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
#### (3) 正規表現の修正
|
|
73
|
+
|
|
74
|
+
closeがクリックされたときの閉じる子要素の判定に使う正規表現の修正
|
|
75
|
+
|
|
76
|
+
修正前：
|
|
77
|
+
```javascript
|
|
78
|
+
var child_ancestor_num = click_ancestor_num+'-'+click_post_num;
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
修正後：
|
|
82
|
+
```javascript
|
|
83
|
+
var child_ancestor_num_pattern = new RegExp(`^${click_ancestor_num}-${click_post_num}(-\d+)*$`);
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
として、以下のようにチェックする。
|
|
87
|
+
|
|
88
|
+
```javascript
|
|
89
|
+
if (ancestor_num.match(child_ancestor_num_pattern)){
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
修正前だと、もし `child_ancestor_num` がたとえば `"0-111-222"` で、 `ancestor_num` が `"0-10-111-2229-76"`のとき、以下の判定
|
|
93
|
+
|
|
94
|
+
```javascript
|
|
95
|
+
"0-10-111-2229-76".match("0-111-222");
|
|
96
|
+
```
|
|
97
|
+
はマッチしてしまうので意図しない動作を引き起こす原因になります。修正後のように正規表現を作ることでこれを避けられます。
|
|
98
|
+
|
|
99
|
+
### 2. getParentNums が再帰を使っていることで起こるエラーについて
|
|
100
|
+
|
|
101
|
+
> コメントが削除された場合、再帰になっているせいで「親が削除されて見つからない」→「too much recursionエラー！」になってしまうのです。
|
|
102
|
+
|
|
103
|
+
なるほどですね。おそらくこのコードは、
|
|
104
|
+
|
|
105
|
+
> 教えて頂いたり拾ったりしたコードを一晩中切って貼ってを繰り返した
|
|
106
|
+
|
|
107
|
+
とあったとおり、力作ではあるのでしょうから、なんとかしたいお気持ちも分かります。しかし、ある投稿（post)が削除される可能性があり、これに対応しようとするとエラーになってしまったという状況は、私からすると、元の回答に書いた、【パターン：あ】を使うことへの所感：
|
|
108
|
+
|
|
109
|
+
> ・・・・・ 直感として思うのは、
|
|
110
|
+
> 「慎重に書かないとバグのあるコードを書いてしまいそう」
|
|
111
|
+
|
|
112
|
+
に当てはまる事態であったりします。
|
|
113
|
+
|
|
114
|
+
つまり、分かり易くいえば、もし仮に、私と貴殿が同じ職場で働く同僚であったならば、
|
|
115
|
+
「ほらみろｗ だから、【パターン：あ】 は辞めとけっていったのに〜ｗ」
|
|
116
|
+
と、ここぞとばかりにdisるだろうなあということですね。
|
|
117
|
+
|
|
118
|
+
ツリーを構成する各ノードの親子関係の操作だとか、ノードの削除、移動などは、プログラミングの勉強にはなりますし、自分で書くとアルゴリズムの勉強になりますし楽しかったりもするのでハマる気持ちも分かりますが、これがもし何らかの製品として本番サーバーに載せるサービスの一部であるなら、こういうツリー操作はまさにDOM操作のお家芸ですから、先達のプログラマーの成果に乗っかった方が良い気がします。（つまり、【パターン：い】を採用するということですね。）
|
|
119
|
+
|
|
120
|
+
さらにより賢明なのは、ツリーの基礎となるグラフ理論の初歩をかじったり、ツリーのノードを一番上から下へ、あるいは、末端のノードから上へ再帰でたどるコードを自分で書いたり、他の人のコードを読んだりして、「やろうと思えば自分で書ける」と思えるだけのプログラミング力はキープしつつ、明らかに先達の作ったコードに乗っかった方がよいときは思いっきり乗っかって楽をして、自分はもっと別の重要なコードを書く方に時間をあてる、みたいな姿勢かなと思います。
|
|
121
|
+
|
|
122
|
+
とはいえ、明らかに大変なのに、【パターン：あ】に猪突猛進した貴殿の勢い、嫌いではありません。
|
1
テキスト修正
answer
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
こんにちは。
|
|
2
2
|
|
|
3
|
-
以下のように修正すると、いかがでしょうか？
|
|
3
|
+
以下のように`if`条件を修正すると、いかがでしょうか？
|
|
4
4
|
|
|
5
5
|
**修正前：**
|
|
6
6
|
```javascript
|