Yoshiki Oshima
, Computer Scientist and Software Engineer, Math Teacher
Date and time of reply: Sun
Does tracking behavior mean that the application is already running and you use your browser's development tools to track the behavior at runtime? Or are you looking at the code and trying to read what it does?
Since various events are set for various elements, I would like to answer by thinking that it is the former.
If you have a running program, click on an element in the DOM tree to see what appears in "Event Listeners", set a breakpoint there, and actually step through it. I think it's actually quick to see. Even if it is a short code, if there is a loop and there are many element screens, it is natural that there are so many event handlers, but if you step on even one, you can see where it starts and ends. That's why.
If it is minified and it is difficult to understand the correspondence with the original source code, of course, it will be executed with the development build. With that in mind, if it's the new JS in the question, I think it's worth considering the option of not using a complicated framework as much as possible. Like Brian Kernighan's words, "Debugging is twice as difficult as programming, so if you use your wisdom in programming, you won't be able to debug." I think it's better to just write simply, rather than using a framework or framework.
You may use React.js, but if you start using a component created elsewhere, the event handler will be registered in a place you do not know, so what will happen later. It's possible that you don't know what you're doing. If that's the case, look inside what's happening if you can, or use the simplest if you have similar components, or if it's really simple, look at the code and then do it yourself. If you take the trouble of writing, there is a possibility that the time and effort of upgrading the version in the future can be greatly reduced.
So, I think it is important for new projects to write simply and reduce dependence on the outside as much as possible.
Views: 140 times See 4 high ratings
Masahiro Ishizuka's profile picture
Ryoga Nawa's profile picture
Ryoga Nawa
, Start studying in 2020
Answer date and time: Sat
I felt that the air of jQuery was fluffy.
There is an event attached to some element of HTML, and it is written in one file. Somehow I understand that it will be very difficult to see if I do not put it together properly.
That's one of the annoyances of not using a framework, isn't it? I think it's probably because it's not componentized, so I use a relatively simple framework or library like Vue.js or Riot.js to combine HTML elements and JavaScript code into separate parts. I think that is the easiest.
If you have no choice but to use jQuery, I think it's best to at least put together the JavaScript code written for each HTML element in the class syntax. You need to transpile to support IE, but is it possible to support browsers that are no longer supported?
Views: 229 times See 2 high ratings
Vitgen
Requested answer
Masahiro Ishizuka's profile picture
Yoshinari Yamaguchi's profile picture
Yoshinari Yamaguchi
, Former manufacturer system subsidiary working bottom engineer (early retirement completed)
Answer date and time: Thu
Thank for your request. I have no experience in JS in practice, so it is only for reference, but I will write it as a connection until other proper answers come. I can't write much about it.
I don't know what language and how it's been learned so far, but it's often the case that when you go from a program that has sources flowing from top to bottom to an event-driven program, you don't know where and what is because of a different way of thinking. I think there is.
First of all, even if you say JS in a nutshell, it will be completely different depending on whether it is plain HTML, CSS, JS, or if you use some framework. Whether it's a framework, HTML is HTML, code is code, styles are different from styles, and others are all in one file.
Well, even if you leave the file separate or one, make sure to separate the markup part, style part, and code part as components, and put in the naming convention etc. and comments firmly. I think it is necessary to understand to some extent without referring to each element.
After that, please leave the document properly if possible. The relationship between each component and the state transition. Writing and commenting on the code is important, but it's often better to document the appropriate figures, tables, and worst bullets than to work hard. I think it's better to write it because it can be retrofitted.
As mentioned above, it may be said that it is too obvious to be helpful, but for your reference.
動作を追う、というのはアプリケーションが既に実行されていて、ブラウザーの開発ツールを使って実行時の動作を追う、ということでしょうか？あるいはコードを見ていて、どのような動作をするのかを読み取ろう、ということでしょうか？
色々な要素にいろいろなイベントが設定されていて、ということなので一応前者だと思って回答したいと思います。
動いているプログラムがあるのであれば、DOMツリーの中にある要素をちくちくとクリックし"Event Listeners"に出てきたものを確認して、そこにブレイクポイントを設定して実際にステップ実行してみるというのが実は手っ取り早いと思います。短いコードであったとしてもループがあったりして多くの要素画面上にあれば、それだけのイベントハンドラーがあるのは当然ですが、ひとつでもステップ実行してみれば、どこから始まりどこで終わるのかはわかるわけですから。
minifyされていたりして元のソースコードとの対応がわかりにくい場合には、もちろん開発用のビルドで実行するわけです。ということを踏まえると、質問にある新規のJSということであれば、なるべくややこしいフレームワークは使わない、という選択肢も検討に値すると思います。Brian Kernighanが言った「デバッギングはプログラミングよりも2倍難しいのだから、プログラミングのところに知恵を使ってしまうとデバッグできなくなってしまう」という言葉のように、新規であれば「工夫したり大量のツールやフレームワークを使うよりは、とにかく単純に書くことを心がける」のが良いと思います。
React.jsくらい使っても良いかもしれませんが、他のところで作られたコンポーネントを使い始めると、まさに知らない間に知らないところにイベントハンドラーが登録されたりするため、後から見るとどうなっているのかわからないということがあり得ます。そのような場合も、できれば何が起こっているのか中を見ておく、あるいは同種のコンポーネントがあれば一番シンプルなものを使う、さらには本当にシンプルなのであれば、コードを見た後で自分で書く、というような手間をかけると、将来バージョンアップするときなどの手間が大いに減らせる可能性があります。
というわけで、シンプルに書く、なるべく外部への依存を減らす、というのが新規プロジェクトで重要になると思います。
ふわっとjQueryの空気が香ったような気がしました。
HTMLの何かの要素にイベントがついてて、それがひとつのファイルにばーーーーっと書いてあったりするんですよね。ちゃんとまとめないとすごく見づらくなるのは何となくわかります。
それがフレームワークを使わないめんどくささの一つなんだよなぁ…というところなんですよね。たぶんコンポーネント化してないのが理由だと思いますので、Vue.jsかRiot.jsのような、比較的簡単なフレームワークなりライブラリなど使って、HTML要素とJavaScriptコードを個別の部品としてまとめてしまうのが一番楽だと思います。
jQueryを使うしかない現場なら、せめてクラス構文で各HTML要素ごとに書かれているJavaScriptコードをまとめてしまうのがいいと思います。IEに対応するためにはトランスパイルをかます必要がありますが、もうサポートが終了したブラウザに対応することってあるんですかね…どうなんでしょう…
リクエストありがとうございます。自分は実務でのJS経験はないのでご参考程度にしかなりませんが、他のちゃんとした回答が来るまでの繋ぎとして書いておきます。あまり、大したことは書けませんが。
今までどんな言語でどのように学習されてきたのか分かりませんが、上から下へとソースが流れるプログラムからイベント駆動のプログラムになると、考え方が違うのでどこに何があるのかわからない、というのはよくあるかと思います。
まず一口にJSと言っても、素のHTMLとCSS、JSなのか、なんらかのフレームワークを使うのかで全く違ってきます。フレームワークにするにしろ、HTMLはHTML、コードはコード、スタイルはスタイルとバラバラにするものもあれば、全てを1ファイルにするものもあります。
まあ、ファイルを分けるか1つにするかは置いておくとしても、構成要素としてのマークアップ部分、スタイル部分、コード部分はちゃんと分けた上で、命名規則等やコメントをしっかり入れるといった工夫をして、各要素を相互に参照しなくてもある程度わかるようにしておく必要があるかと思います。
あとはできればちゃんとドキュメントを残してください。各コンポーネントの関連とか、状態遷移とか。コードの書き方やコメントも重要ですが、そこを色々頑張るよりも適切な図や表、最悪箇条書きでも、ドキュメントにまとめておいた方が理解の助けになることはよくあります。後付けでも良いので書いておいた方が良いと自分は思います。
以上、そんなの当たり前すぎて参考にならない、と言われるかもしれませんが、ご参考まで。
0 コメント:
コメントを投稿