Tu się pojawia moje pytanie, czy dobrze to podzieliłem?
Okaże się w praniu. Przy tak małym kawałku kodu (~100 linijek kodu), to nawet jakbyś miał to napakowane w jednym pliku i nawet bez zachowania żadnych większych zasad, nie byłoby szkody. Bo ogólnie mam wrażenie, że z tego kodu to niewiele za bardzo wynika i jest podzielony za wcześnie, zanim w ogóle się zdecydujesz, co chcesz tak naprawdę zrobić. Chyba, że to część większej całości, ale właśnie wygląda jak coś bardzo surowego, co nic nie robi, a tylko pachnie.
to są na razie tylko szkielety klas
protip: najlepiej jak coś się robi za pierwszym razem, to robić mięsko, pisać prosty kod, który robi, co ma robić, nie bawić się w jakieś szkielety i wysublimowane wzorce. Dopiero potem, jak już wiesz, co chcesz zrobić (plus jakie problemy mogą wyniknąć po drodze), to wtedy można się pobawić w podejście top-down.
if(TodoController.instance)
return TodoController.instance;
TodoController.instance = this;
po co ten singleton? Nic ci to nie daje. Jak chcesz mieć jeden obiekt, to możesz po prostu zrobić tak:
const app = {
model: new TodoModel(),
view: new TodoView(),
openAbout(){
this.view.openAbout();
},
expandProjectsMenu(){
this.view.expandProjectsMenu();
}
};
to samo w tym przypadku, co osiągasz z singletonem, ale krócej.
Ale z drugiej strony, czemu zakładasz, że kontroler ma być tylko jeden (i ten jedyny kontroler będzie miał 1 model i 1 widok)? A co jeśli będziesz chciał mieć ileś modeli i widoków naraz?
this.projects_list = new Map();
this.addProject("default");
zdecyduj się, albo camelCase albo snake_case (a w przypadku JSa ogólnie przyjętym standardem jest camelCase). Poza tym jak list, to już nie musisz robić liczby mnogiej (lista projektów = projectList).
for(const property in task_data)
To z const ci działa? Wow. Ja zawsze z let robiłem.
No ale const
ma nawet sens, bo jeśli wiązanie property
jest robione dla każdej nowej iteracji, to mimo, że wartość property
będzie ciągle inna, to jednak będzie to ciągle nowa(!) zmienna, więc nie będzie przypisania na nowo, więc faktycznie może być const (tzn. chyba to tak działa. kiedyś to próbowałem zrozumieć dokładniej czytając specyfikację, ale specyfikacja JavaScriptu to nie jest przystępna lektura. Chociaż w nieco bardziej przystępny sposób to tłumaczy książka You don't know JS: https://github.com/getify/You-Dont-Know-JS/blob/8861041133f496edce0d03885e2e998d50c3414a/scope-closures/ch5.md#loops )