Uncaught TypeError: Class constructor ExtensionJs cannot be invoked without ‘new’

Uncaught TypeError: Class constructor ExtensionJs cannot be invoked without ‘new’

クラスを継承しようと思ったのですが、このエラーが出てうまくいきませんでした。

結論から言うと、拡張子が .js のファイルからクラスを継承しようとするとこのエラーが出るようです。もしかしたらうちの環境だけで普通はこんなことで行き詰まったりしないのかもしれないですが、自分はこれで一日潰してしまったので同じエラーで困る人が出たときのために情報を残しておきます。

Reactを利用している場合は、JSXの記述がないファイルでも拡張子はすべて .jsx にしておいた方がいいのかもしれません。

Reactで実際にアプリケーションを作ってみて感じたこと

日本語でReactについて述べられている記事はまだまだ少なく、英文サイトを読む時間も多い現状ですが、その現状で実際にReactを使ってアプリケーションを作ってみて感じたことを、ありのままに語ってみようと思います。

現在、日本人でReactを触っている人たちはアーリーアダプター(初期採用者)層に当たるためか、レベルの高い人が多いです。記事に含まれる専門用語の多さや、語り口の難しさからそういった印象を受けます。自分のように趣味プログラマーに毛の生えたレベルの人間で、Reactを触っている人は他にいないんじゃないかと思えてくる日々ですが、それでもなんとか頑張っています。

Reactを触ってみて感じたのは、仮想DOMという仕組みはとても優れているということです。サクサク更新されて、一度Viewの部分を作ると、以後は状態を更新するだけで自動的にViewも更新されるのが非常に素晴らしいです。サイトの規模が大きくなってくると、自分の脳内でDOMを組み立てるのが辛くなってくるので、そこに労力を割かなくてよくなるのはすごく楽です。

こんな感じにReactが優れている点について述べられている記事は多いですが、悪い点について述べられている記事はあまりないように思いますので、自分はReactのダメな部分について簡単に語ってみようと思います。

自由度が高すぎる


ReactはViewの部分だけを担うというコンセプトで作られています。View部分だけなのでアプリケーションを作るときに必要になるパッケージは別途入れなければならないのです。良いように言えば、作り手が好きなパッケージを採用して自由度の高い構成にすることができるということになるのですが、実際のところ、あれこれ入れるのは非常にめんどくさく感じます。他パッケージごとに情報を調べて、それが必要かどうかを判断し、また必要なら学習コストを支払わなければならないのです。

例えばReactについて調べてるとよく名前が上がるパッケージに、Redux、Immutable.jsなどがあると思いますが、Reactユーザー中で、これらのパッケージを採用している人と採用していない人に別れることになります。当然、双方コードの書き方は変わってきます。同じ部分について書かれているのに書き方が違うのです。自分のような初心者は情報を調べているときによく混乱させられるのですが、とにかく一貫性とまとまりがないのです。

非同期通信のやり方でもredux-thunk、redux-saga、コンテナに直接書く派に分かれており、本当にややこしい。必要最低限の機能を揃えるための道筋が複数あるので、各自がバラバラに進んでいて、複数人で作業するときは大変だろうなと思わされます。

学習コストが高い


React界隈はとにかく覚えることが多いです。普通にアプリケーションを作ろうとするだけで、各パッケージの公式サイトや、GitHubにアクセスして英語のドキュメントを眺める作業を強制される状態に陥ります。ひとつの高いハードルを超えれば終わりという感じではなくて、中サイズのハードルを何度も超えさせられる感じになるのが、逆にしんどいです。

日本語でReactの記事を書いているプログラマーの方々からは、それらをさも簡単にこなしているような印象を受けるのですが、僕のような末端のプログラマーには本当に辛い作業なのです。概念が難しい、英語の理解に苦しむ、そもそも情報がない。一通りできるようになるまで、あちこち調べ回る作業をこなさなければなりません。

基本パッケージにまとめて欲しい


自由度が高いせいで、あちこち駆けずり回ることを強制され、学習コストが高くなっている。これらの問題を解決するために npm install react –save 全部これだけで済むようにして欲しいです。ReduxとImmutableは本体に取り込んで、後は非同期通信の方法を公式でしっかり定めて、みんながその方法で実装するようにしてくれればいろいろ楽になりそうなんですが。

ReactはViewだけを担うというコンセプトのせいか、できるだけ小さくなろうとしていて、そのせいで逆に複雑になってしまっているように感じます。

僕のようなレベルの人間がサクサクとReactを扱えるようにならないと、本当の意味での普及は難しいのではないかと思います。Facebookにいる優秀な開発者の方々には底辺プログラマーの気持ちはわからないかもしれませんが、切実に願います!

最後に


文句が多いのでReactについて調べている人が読むと、印象が悪くなってしまうかもしれませんが、Reactを導入するメリット自体はとても大きいです。現在、オリジナルのソーシャルボタンを作れるアプリケーションを作っているのですが、途中で方針転換があり、jQueryで書いていた部分をReactに書き直しています。

そこで感じたのは、我流のDOM管理が、React (&Redux)のルールに従って管理されるようになるので、構成がシンプルでわかりやすくなって、ごちゃごちゃしなくなります。ここが一番のメリットですね。Viewを各部品ごとに作っていき、それを一回配置すると、後は状態を更新するだけでDOMに反映されるようになる。昔ながらの手作業をルール化、システム化したような感じです。

学習コストが高くしんどいことも多いですが、その分見返りもあるので、チャレンジする価値はあると思います。ただし、現状は環境がいいようには思えないので気軽には勧めにくいです。頭の良さか、学習意欲の高さ・モチベーションが必要になります。

自分の場合はjQueryをベースにサイトを作っていた結果、グチャグチャになってしまって、新しい技術を導入せざるを得ない状況になってReactを始めました。僕と同じような状況に陥った方なら、賢くなくてもモチベーションでなんとかできるのではないかと思います。

一度、簡単にでも使えるようになると良さを感じられるので、興味のある方はぜひチャレンジしてみてください。

退化しました

すでにソーシャルボタンを出力するコード自体はほぼ完成しており、しばらくソーシャルボタンを作成するページを作っていたのですが、なんと途中でまたもコードの大幅書き直しが発生しました。

画像はWordPressのプラグイン画面なのですが、これはソーシャルボタンを作成するページで、ここで画像をアップロードして設定を行うとWordPress上でソーシャルボタンが表示されるという仕組みになっています。

普通のサイトでも利用できるように、ソーシャルボタンの作成が行えるページを公式ページとしても公開する予定なのですが、このページをなにも考えずjQueryで作っていたのです。WordPressはjQueryが利用されているので、深く考えずにそのまま。

このWordPressのページと、公式ページのコードは共通化しようと考えていたので、当然、Game Users内に設置する公式ページもjQueryになるわけです。

jQueryベースはもうやめて、Reactをメインにして行こうという高い目標を立てたにも関わらず、なぜ未だに古いシステムで作っているんだ?Game UsersをReactで書き直そうとしていた高い志はどこへ行ったんだ?という疑念が生じ、jQueryで書いていたソーシャルボタン作成ページをReactで書き直すことになりました。

結構、進んでいた段階での書き直し作業。しかも実際、進めてみるとReactの勝手がわからず、サクサクというわけにも行かず、どんどん時間が過ぎていきます。

本当になにやってんだろうなぁ。当初すべてPHPで書いていたのをJavascriptに書き直した件も合わせると2回目の書き直し作業。さすがにアホすぎて怖くなってくる!

まだ1/3

ブログの更新が疎かになってしまいました。記事を書くのって結構脳を使うので、制作作業後にやるのは辛いものがある。…という言い訳でしばらく放置してしまいました。せっかくブログを作ったんだから、もうちょっと真面目に更新しないと。

2017/5/12 進捗状況

画像を見てもらうとわかりますが、エディットする項目が非常に多くなりました。ずらーっと縦に長いページに羅列されるフォームの数々。この値も編集できるようにした方がいいよな、と思いつくまま追加していくとこんな感じになりました。細かく編集できるのはいいのですが、ユーザーの方にめんどくさそうに思われるんじゃないかと、ちょっと心配しております。

進捗状況的には全作業の1/3くらいは終わったかな?というところです。1ヶ月かけて1/3は、さすがに時間がかかりすぎに思いますが、この後、フキダシを使わないバージョン(画像にシェア数を重ねるタイプ)と、ソーシャルボタンの公式ページ、課金システムを作るつもりなので、まだまだ作業が終わりそうにありません。

課金システムについて説明すると、ソーシャルボタンを使うとネコの画像が表示されてリンクが貼られるのですが、そのリンクを外したい方は課金してくださいというシステムにしようと思っております。Web制作の現場ではWordPressの案件が結構多いようなので、そういう形でWordPressを商用利用しているユーザーの方が有料プランを利用してくれるとありがたいな、という思惑で作っています。

WordPressのテーマを作って収益あげてる人もいるみたいなので、うまくいってくれると嬉しいのですが。

WordPressのプラグインだけでなく?

現在の設定画面

前の記事から6日も経ってるのに進みが遅い!

なぜ進みが遅くなっているのかというと、途中で方針転換があったためです。

当初はWordPressで使えるプラグインの構想だったのですが、作っていくうちに、どうせなら普通のウェブサイトにも使える方がいいよな?ということで一部がやり直しになりました。

WordPressはPHPで動いているのですが、PHPでソーシャルボタンを出力する仕様にすると利用できない環境が出てきてしまうため、Javascriptでコードを出力する仕様にしたのです。数日かけて書いたPHPのコードを書き直す悲しさ、モチベーションの上がらなさでこうなってしまいました。

毎回、自分はこうなってしまうんだよなぁ。自分なりにしっかり構想を練っているつもりなんですが、作っていくうちに構想がどんどん膨らんでいき、同じ部分を何度も書き直して無駄に時間が費やされるのです。

これ客だったら最悪なクライアントですね。途中で方針転換を繰り返して制作者に余計な作業を増やすという。他人を巻き込んでこんなことをしていると非難轟々になりそうなので、いい加減学習したいところなのですが、妄想だけは無駄に膨らむタイプなので、この病の治療は無理かもしれません。

いつの日か、誰かに作業を依頼できる身分になれたら、最初から仕様変更ありの契約でお金を上積みしとかないとダメですね。

MariaDB – DEFAULT CURRENT_TIMESTAMP

WordPressのプラグイン制作、なかなか手ごわいです。独自の書き方を学ばないといけないので、慣れるまで調べることが非常に多いです。

WordPressはデフォルトでjQueryが読み込まれるのですが、そのバージョンが1.12.4でとても古いのです。今後、jQuery依存のライブラリを利用するときに、バージョンの問題で使えないといったことが起こると困るので、最新のものを読み込もうとしたのですが、そのためにはまず古いものを読み込まないという処理をしなければなりません。

たったそれだけのことでも上記のような感じで、独自の関数をいくつか利用して書かなければならないのです。これが本当にわけがわからない。

WordPress Codex 日本語版

一応、リファレンスも用意されているのですが、どこになんの項目があるのか分かり辛い上に、解説が難解で理解するまでに時間がかかるのです。

プラグインをサクッと完成させてから、Game Usersの開発も進めていこうと思っていたのですが、世の中そんな簡単には行かないもんですね。作っているうちに追加したい機能も増えてきたので、当初思ってたよりずっと時間がかかってしまうかもしれません。

MariaDB 日時のデフォルト値


プラグインで使うデータベースのテーブルを作成するコードは以下になるのですが、これを書いているときに、便利な日時のデフォルト値の設定方法を知りました。

datetime_renewal DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NOT NULL

データベースの日時のデフォルト値をこのように設定しておけば、Updateするだけで自動的に日時が更新されることを知って、ちょっとしたショックを受けました。今までデータベースを更新するたびに 0000-00-00 00:00:00 形式で日時を作成してから保存してたのに、あの手間はなんだったんだという。

すごく便利なので、みなさんもぜひ使ってみてください。


追記: 記事を書いてすぐに、これってもしかして新しい機能なんじゃないかと気になって調べてみたところ、MySQL5.6.5からの機能でした。またMySQLが古い環境だと、DEFAULT CURRENT_TIMESTAMPが2つあるとエラーが出るようなので、どのみち上に挙げたSQL文は使えません。

公式によるとWordPressの推奨環境は、MySQL 5.6 / MariaDB 10.0以上ですが、MySQL 5.2.4でも動くようです。プラグインは環境が様々なので、ちゃんと考えてコードを書かないとダメですね。

 

プラグインの設定画面

プラグインの制作は設定画面を表示するところまで来ました。Bootstrapのタブを利用しています。これから設定画面の中身を作っていきます。

Chrome Developer Tools便利!

現在、WordPressのソーシャルボタンのプラグインを作っているのですが、適用されているテーマのスタイルシートが邪魔をして思うようなデザインにできないという問題に直面しました。

WordPress ソーシャルボタンサンプル

黒猫の周囲を囲むように存在している、この謎の白枠に2時間以上費やすことに!

marginでもなく、paddingでもなく、borderでもない。自分なりにいろいろ探してみたのですが、原因がまったく特定できず、お手上げ状態になったのですが、ChromeのDeveloper Toolsにスタイルシートの欄があったことを思い出し、開いてみるとそこに答えが書いてありました!

box-shadow

box-shadow…。ほとんど使わないから存在を忘れていました。便利なことにDeveloper Toolsの画面でチェックボックスを外すと、ブラウザ上のデザインにも変更が加えられます。他の人が作ったものはなにが適用されているのかわからないので、この機能は非常にありがたいですね。

ChromeのDeveloper Toolsはいろいろ機能がついてそうなので、一回ちゃんと勉強した方がいいかもしれません。

 

フリーキャット

ちなみにこの黒猫はクレジットを表す画像で、Game Usersのトップにリンクが貼ってあります。ソーシャルボタンを使ってくれた方のブログから、Game Usersにアクセスしてくれる人が増えたらいいなという目論見でつけております。

こういうのってスパム認定されるんでしょうか?SEOについての知識がないのでちょっと心配です。

ソーシャルボタンのサンプル

ソーシャルボタンのサンプルをスタイルシートで作ってみました。

画像のボタンは全部素材サイトで集めたものです。こんな感じで同じように画像を集めてアップロードするだけで、誰でも自分好みのソーシャルボタンを作れるようにしたいのです。

ただプラグインの設定画面で画像のアップロードが自由にできるのかわからないのが不安ですね。もしできなかったら、プラグインフォルダに最初から画像を含めるしかないので、サンプルのような多様なボタンが作れなくなってしまいます。

自分がデザインセンスのある人間なら、オリジナルの画像をいろいろ提供できるのですが、こればっかりは才能がないのでどうしようもないですね。

でも、もし構想どおりに作れたら、なかなか面白そうなプラグインになりそうな気がします。

WordPressのソーシャルボタンを作りたい

開発環境の作り方についての記事作成は一通り終わり、今なにをしているかというと、WordPressのソーシャルボタンを作ろうとしております。

プラグインで良さ気なのを探してみたのですが、外国製は、はてなやLineに対応しておらず、日本製のは公式のソーシャルボタンを使ってるので重く(非同期ではない)、どちらもいまいち気に入らなかったのです。

そこでGame Usersで使ってるソーシャルボタンをWordPress用に改造して独自につけようと思ったのですが、どうせやるなら他の人も使えるようなプラグインとして公開しようと考え、今、勉強しながら作り始めております。

非同期でカウントを表示して、さらにボタンのデザインをいじれるようなものにしたいと考えています。テーマやテンプレートのような形で、好きなデザインのボタンをアップロードして使うようなイメージ。

実際できるかどうかわからないので構想だけで終わってしまうかもしれませんが、とりあえず頑張って作ってみます。

 

記事書くのって大変!

開発環境の作り方について一通り情報を揃えようと思って、とりあえずXAMPPのインストール、設定、アップデートについての記事を書いてみたけど、めちゃくちゃ大変でした。

ここ何日かコードを書かずにずっとテキストを書いてる感じなんですが、本当に時間があっという間に過ぎていきます。世の中、役に立つ記事を書いてる人々はその情報を提供するために、すごい時間を費やしてるんだなということに気づかされました。

そもそもなぜXAMPPの導入記事を書く必要があるんだという話なんですが、これは開発環境の構築に自分もXAMPPを使っているからなんです。Reactに手を出そうとしてるのに、未だにXAMPP使ってるの?と言われそうですが、手軽さが気に入って初心者の頃からずっとXAMPPを愛用しております。

レベルの高いプログラマーの方々はなんとなくMacや仮想環境のLinuxを使ってそうなイメージですが、実際、みなさんはどういう環境で開発をしているんでしょうか。ずっとXAMPP使ってるような人間はまれなんかな。