コツは、なぜそのフレームワークが作られたのかについて触れることです。
だいたいはREADMEの一番頭とか、あるいは本人やコミッターのブログになんかに作者の思想とか、フレームワークのコンセプトについて書いてあります。
それらを読んだりしていると「なぜ既存のやり方やフレームワークじゃだめだったのか」というのがみえてきます。
ここがわかっていると、ドキュメントを読まなくてもだいたいどういうAPIが生えているのか、あるいはどういう流れで実装していくものなのかの想像が付く状態になるはずです。なぜならあなたにはそのフレームワークが何を解決するために生まれたものなのかがわかっているからです。
あとは公式のチュートリアルをこなして想像と実際のギャップを埋めていきましょう。
ここで想像と、提供されているAPIに著しい差がある場合は以下の可能性が考えられます:
- あなたの理解が間違っている/乏しい
- コンセプトがあなたの好みにあっていない
- 実装者の理解が間違っている/実装力不足
- まだライブラリが枯れておらず、実装が間に合っていない
- 思想とか特に存在してない
おそらくは高確率で一番なので、チュートリアルをこなしつつ色々なドキュメントを読んで再学習しましょう。
思想が特に存在していないライブラリとかも稀によく存在しているので、そういう場合は諦めます。
チュートリアルを終わらせたらもっと複雑で、実際的な機能をもつものの実装に移ります（権限があるならば、業務にぶちこむのもありでしょう。実験だよ実験！）。
実践的なものを作っていると、チュートリアルレベルでは考えなくて良かった様々なものに対する問題が立ち上がってくるでしょう。ここで気をつけないといけないのは以下のことになります:
- 複雑化するモジュールの構成をどう管理するか
- エラーのハンドリングまわり
- 値の整合性（バリデーション）
- パフォーマンスの調整（非同期サポートとか）
この辺に対するガイドラインが存在しない、サポートが薄い場合、特にエラーのハンドリングまわりのサポートが未熟な場合はそのライブラリがまだ若いか、実践レベルで利用しているユーザーが存在しない可能性があります。
時間とモチベーションにあふれている場合はコントリビューションチャンスですが、忙しい業務などでは避けたほうが無難だとおもいます。
まとめ
いきなり思想がどうとか、作者のお気持ちだとか、国語の教師かよテメーって感じではありますが、結局がこれが一番効率よく習得できます。
例えばReduxですが、ぱっとみのボイラープレートの多さが異常なだけで、フレームワークが提供（強制）しているAPIはほぼなく、大体はただの関数です。丸暗記とコピペでアプリを組もうとするとこれほどシンドいフレームワークもないかもしれないですが、コンセプトさえちゃんと理解すれば覚えるのは一瞬です*1。
APIの丸暗記だけの知識はそのフレームワークが死んだら終わりますが、思想への理解は次に繋がります。
なぜなら次世代のフレームワークというのは、前世代の否定か洗練だからです。例えばフロントエンドフレームワークの進化の歴史はstateの管理とviewへの反映方法の洗練（Railsが歪める前のMVCの移植）からはじまっています。fluxはMVCを洗練させたもの、そしてstate -> viewの部分ではDOM操作を否定する方向に進化しています。
そういうところさえ押さえておけば、次にまた新しいものが出てもちゃんとついていけるんじゃないかなと。
ちなみに僕は最近仕事でRailsを使う羽目になっていてヒーヒー言っています。大抵のやり方は気に食わず、やろうとすることがことごとくうまくいかないのでたぶん思想レベルで相容れないんだとおもいます。そういうこともあるとおもいます。
だんだん何言いたいのかわからなくなってきたので今日は以上です。
