Saya akan bagi idea, tetapi saya tidak akan menerangkannya secara terperinci, kerana saya tidak suka menghubungi orang lain... Saya akan memberi anda rancangan, sekurang-kurangnya gunakan otak anda untuk berfikir tentang ia.
Pertama sekali, kod berikut tidak menggunakan $modal ui-bootstrap, tetapi $modal ng-strap Sebabnya saya rasa kualiti kod yang kedua adalah lebih baik daripada yang pertama, tetapi yang kedua adalah agak baharu dan API tidak sebaik yang sebelumnya Perfect, jadi anda perlu mempunyai kemahiran hands-on yang kuat, tetapi ini tiada kaitan dengan pengembangan perkhidmatan $modal yang akan saya bincangkan seterusnya.
Kedua, anda perlu mempertimbangkan isu ini sebelum melanjutkan perkhidmatan $modal awam:
Apa yang boleh digunakan semula? Yang manakah perlu (mungkin) baru dinyatakan setiap kali? (templat, parameter, kaedah, dll.)
Apakah kaedah panggilan yang dijangkakan? Apakah rupa hasil pulangan?
Berapa tinggikah keperluan skalabiliti dan fleksibiliti?
Tiada jawapan yang jelas untuk soalan ini pada mulanya, tetapi anda perlu mensimulasikan jawapan dalam fikiran anda, kerana ia akan menentukan cara menulis perkhidmatan anda.
Langkah pertama ialah menyediakan parameter lalai; ini adalah parameter yang disediakan oleh $modal asal Mula-mula tetapkan keadaan awal (mengikut keperluan anda sendiri)
Langkah 2: Tulis kod sambungan harta bagi perkhidmatan baharu supaya perkhidmatan baharu boleh mempunyai keupayaan sambungan harta yang sama seperti $modal asal
Kemudian terdapat definisi ConfirmModal, yang akhirnya mengembalikan $janji, supaya pemanggil boleh mengembangkan logik perniagaannya, saya menambah beberapa komen pada perkara utama, dan selebihnya boleh difahami oleh anda sendiri:
Saya akan bagi idea, tetapi saya tidak akan menerangkannya secara terperinci, kerana saya tidak suka menghubungi orang lain... Saya akan memberi anda rancangan, sekurang-kurangnya gunakan otak anda untuk berfikir tentang ia.
Pertama sekali, kod berikut tidak menggunakan $modal ui-bootstrap, tetapi $modal ng-strap Sebabnya saya rasa kualiti kod yang kedua adalah lebih baik daripada yang pertama, tetapi yang kedua adalah agak baharu dan API tidak sebaik yang sebelumnya Perfect, jadi anda perlu mempunyai kemahiran hands-on yang kuat, tetapi ini tiada kaitan dengan pengembangan perkhidmatan $modal yang akan saya bincangkan seterusnya.
Kedua, anda perlu mempertimbangkan isu ini sebelum melanjutkan perkhidmatan $modal awam:
Tiada jawapan yang jelas untuk soalan ini pada mulanya, tetapi anda perlu mensimulasikan jawapan dalam fikiran anda, kerana ia akan menentukan cara menulis perkhidmatan anda.
Langkah pertama ialah menyediakan parameter lalai; ini adalah parameter yang disediakan oleh $modal asal Mula-mula tetapkan keadaan awal (mengikut keperluan anda sendiri)
Langkah 2: Tulis kod sambungan harta bagi perkhidmatan baharu supaya perkhidmatan baharu boleh mempunyai keupayaan sambungan harta yang sama seperti $modal asal
Kemudian terdapat definisi
ConfirmModal
, yang akhirnya mengembalikan $janji, supaya pemanggil boleh mengembangkan logik perniagaannya, saya menambah beberapa komen pada perkara utama, dan selebihnya boleh difahami oleh anda sendiri:Contoh panggilan:
Untuk templat, cuma rujuk $modal asal dan tulis semula sendiri Kod itu tersedia di github, itu sahaja.