narkkil / ruokakauppacom-tsoha Goto Github PK

Separate SQL to different models

API sessions work as intended but AngularJS drops sessions after refresh

Ahoy, seilori!
Nyt näköjään tuotesivun hidastelu safarilla korjattu. Nopeus on hyvä, mutta mitä tapahtui. Mentäessä takaisin settings sivulle, saa se pyörimään "beach ball of deathin" hetkeksi. Tätä ei tietysti tapahtunut chromella, kuten ei myöskään luultavasti sun mäkillä :)

Magee toi aterioiden randomointi! Ei mitään järkeä tässä 👍
Tein uuden käyttäjän, mutta sen tuhoaminen ei onnistunut. Ei myöskään ilmestynyt tuota varoitusta "Are you sure..".
Tämä on hieman copypastea "if (isNotAuthenticated(user))..". Ei paha, jos se kolme kertaa kirjoitettu, mutta laajemmassa käytössä joku authentikointimetodi olisi paikallaan.

Tuo Angular.js maailma on mun mielestä kummallinen. Ensin vuosi kaudet yritetään tehdä puhdasta hötömölöä ja sit ruvetaankin kirjoittavaan js kutsuja hötömölö tagien sisällä. Seuraavaksi varmaan kirjoitetaan kaikki tyylitkin samaan tagiin (kuten sulla oli muutamassa kohdassa). Onhan noissa yksinkertaisissa valmiissa komennoissa jotain hienoa ja hipsteriä, mutta joku siinä hieman tökkii, noin niin kuin ajatuksena. Toisaalta ammattilaisten suunnittelema arkkitehtuuri ja testattu toiminnallisuus on kyllä houkuttelevia ominaisuuksia. :)

Vaikka en javascritpiä kovin paljoa ole kirjoittanut, niin koodisi on hyvin luettavaa ja ymmärrettävää. Sovellus on oikein siisti, vaikka ei sillä taida olla mitään järkevää käyttötarkoitusta.

:)

Koodin yleinen laatu hyvää, toiminnallisuus jäsennelty MVC-arkkitehtuurin mukaisesti, muutamia poikkeuksia lukuun ottamatta. Esimerkiksi lib/controllers/api.js kontrolleri näyttäisi sisältävän SQL-kyselyn. Ja sessions.js controlleri näyttäisi kovakoodaavan ihmeellisiä arvoja resUser olioon.

Käyttäjien luomisen CRUD näyttäisi toimivan lähes moiteetta, kuitenki email kenttää ei koskaan käsitellä tai talleteta mihinkään, eikä virheellisen nimen (käyttäjätunnus on jo olemassa) syöttämisestä rekisteröityessä ilmoiteta millään tavalla.

Käyttäjältä tullut data bindataan järkevästi kaikissa paikoissa kyselyihin, välttäen SQL-injektiot. Kyselyissä on kuitenkin käytetty paljon subqueryja ja kovakoodattuja merkkijonoja, joita ainakin itse pitäisin huonona käytänteenä. Itse välittäisin halutun kategorian nimen/id:n metodille parametrina ja subqueryistä pääsee eroon esimekriksi JOIN-lausekkeella. Esimerkiksi tuotteiden listaus sivun kyselyn voisi muuttaa JOIN-lauseketta käyttävään muotoon SELECT products.* FROM categories JOIN products ON categories.id = products.category WHERE categories.name LIKE "Ruoka ja juoma".

Vertailtaessa merkkijonoja SQL-kyselyissä tulisi käyttää LIKE-operaatiota yhtäsuuruus-operaation sijaan. LIKE-operaatio osaa vertailla merkkijonoja joissa eri merkistö, kun taas = on bittitason vertailuoperaatio.

Schema sisältää puutteita lähinnä favorites taulussa, taulusta puuttuu muutama viitte toiseen tauluun, kentät ovat kuitenkin jo paikallaan. En myöskään asettaisi kaikkia tekstikenttiä TEXT tyyppisiksi, usein on järkevää rajoittaa esimerkiksi käyttäjätunnuksen pituutta tai tuotekategorioiden nimiä, koska mielivaltaisen pitkän merkkijonon esittäminen verkkosivulla esimerkiksi otsikossa voi rikkoa sivun layoutin täysin.

SQL-tietokannat ovat nykyään erittäin edistyneitä ja niiden avulla on esimerkiksi mahdollista suorittaa listan sekoittaminen sekä rajaaminen seuraavasti ORDER BY RANDOM() LIMIT 10;. Tietokannat tarjoavat nykyään oletuksena erittäin paljon erilaisia toimintoja,ja yleensä kannattaakin tutustua käytettävän tietokannan toimintoihin ennen niiden toteuttamista itse.

Erittäin siistin oloinen toteutus ja aivan mahtava sovellus. Ja vielä loppuhuomautuksena koodi on hyvin kommentoitua /* I'm so sorry */ /* Please forgive me... */.

Tämän illan ateriana toimii delicious five-star™ meal!