Weergave frameworkrefactor - Development-iteratie #135

Development-iteratie #135 is opgeleverd. In deze sprint hebben we onder andere gewerkt aan de release van ons verbeterde weergaveframework, onze rml-parser en de verbetering van de Pricewatch-ervaring.

Weergave frameworkrefactor

Naast alle nieuwe features die we bij Tweakers bouwen, bugs die we oplossen en optimalisaties die we doorvoeren, zijn we achter de schermen druk in de weer om van een groot deel van onze technical debt af te komen. Ongeveer dertig procent van de developmentcapaciteit wordt dan ook gereserveerd om puur technische projecten af te ronden. Zo zijn we in het verleden druk aan de slag geweest met het correct toepassen van Dependency Injection, waarvoor we de standaard DI-module van Symfony gebruiken, met het omzetten van css naar scss en met het introduceren van Twig.

Naar aanleiding van die laatste toevoeging hebben we in de afgelopen sprints verdere verbeteringen uitgewerkt. Voordat we Twig gebruikten, genereerden we de html met php-code. Voor het 'framework' waarbinnen alle content, zoals header, footer, achtergrond enzovoort, wordt geladen, gebruikten we dan ook nog steeds php-code. Dat was bovendien door de jaren heen uitgegroeid tot een wat rommelige structuur.

We hebben er daarom werk van gemaakt om juist die belangrijke, centrale html via Twig te renderen, in plaats van via php. Daarbij is ook de manier vernieuwd waarop assets als JavaScript en style-sheets werden ingeladen. Als het goed is, heb je er als eindgebruiker weinig van gemerkt, maar intussen komt de basis van de html voor het leeuwendeel van Tweakers nu vanuit Twig-templates.

Waarom deze refactor als je er toch niets van merkt? Deze vernieuwde code is nu beter leesbaar, is makkelijker testbaar, is sneller aanpasbaar, heeft een betere scheiding in verantwoordelijkheden en is ook voor nieuwe en andere developers beter onderhoudbaar. Mocht je toch nog ergens een bug in de rendering van Tweakers tegenkomen, laat het ons vooral weten in het welbekende 'stoute bugs'-topic.

Nieuwe rml-parser

Enige tijd geleden hebben we de 'eigentijdprojecten' ingevoerd. Dit is een initiatief om projecten die door de developers zelf worden aangedragen, van ruimte te voorzien. Ruim een jaar geleden is crisp daarom in eigen- en werktijd begonnen aan het schrijven van een geheel nieuwe rml-parser voor het converteren van de ubb-stylemarkup naar html. Deze kan gebruikt worden bij onder andere reacties, productreviews en op het Forum. Rml staat voor 'react markup language', wat een referentie is naar de forumsoftware die we in 2002 in gebruik hebben genomen en die een parser bevatte die een uitgebreide variant van (u)bb-code ondersteunt.

Op andere plekken van de website gebruiken we een verzameling reguliere expressies om ubb-stylemarkup om te zetten, maar het bleek lastig om daarmee te blijven voorzien in nieuwe wensen waarbij ingewikkeldere constructies en geneste tags gebruikt moesten kunnen worden. Omdat de forumparser moeilijk te hergebruiken was buiten de context van het Forum, is destijds al een eigen parser gebouwd met vergelijkbare ondersteuning. Het was toen al de bedoeling ooit eens naar één enkele parser voor de hele site over te stappen, maar dat is er nooit van gekomen.

Na intensief onderzoek van de, inmiddels oude, rml-parsers, kon de conclusie worden getrokken dat deze monolitische monsters met vele duizenden regels veelal procedurele code niet heel geschikt meer waren om multifunctioneel inzetbaar te worden gemaakt. Opnieuw beginnen was dan ook beter. Nu, ruim een jaar later, is de nieuwe parser feature-complete en klaar om te worden ingezet. Aangezien een groot deel test-driven was ontwikkeld, hebben we ook meteen een nette testcoverage van zo'n 95 procent.

In deze iteratie hebben we voor de reacties en productreviews de huidige parser vervangen door deze nieuwe. In de komende tijd zullen we de nieuwe parser ook op alle andere plekken, inclusief het Forum, gaan inzetten.

Meer koptelefoons in de Pricewatch

Zoals we in eerdere iteraties al hebben meegedeeld, is onze productcontentafdeling druk met het automatiseren van productinformatie in de Pricewatch. Hier bundelen we de krachten van de kwantiteit van een dataleverancier met de kwaliteit en expertise van het contentteam. In deze iteratie heeft dit tot gevolg dat we in staat zijn om driehonderd koptelefoons toe te voegen.

Community pick

In de komende sprints hebben we weer ruimte om een door de community gekozen feature te ontwikkelen. Stem in de onderstaande poll op jouw favoriet.

Welke feature wil jij laten bouwen?

Tweets en Instagramposts kunnen embedden in forumposts

40,7%

Forumtopics kunnen filteren op posts met opgestoken duimpjes

30,8%

Productcategorie weergeven in rml-output van wenslijst

14,8%

Inhoud van dm-thread weergeven in bekijk/reageer op bericht

13,8%

Aantal stemmen: 878. Deelname gesloten op 18-07-2018 12:00. Stemmen is niet meer mogelijk.

Reacties (36)

[BarôZZa]

Een feature die ik op m'n eigen community had gebouwd en volgens mij ook wel interessant zou zijn voor Tweakers is het omzetten van URL's naar wat het meest logische is. Dus ipv specifieke embedcodes werden urls naar afbeeldingen meteen omgezet naar images, werden urls naar Youtube meteen als Youtube embed (met een preview plaatje die bij een klik vervangen werd door de Youtube iframe code zodat de gebruikers niet meteen getracked werden op elke pagina) en dito voor urls naar Facebook en Twitter. Gifjes werden zelfs omgezet naar MP4, afbeeldingen automatisch gedownscaled. Bij een gewone link kan je à la Facebook de titel, description en preview tonen.

Voor het embedden kan je gebruik maken van onder andere oEmbed.

Het maakt het posten een stuk makkelijker voor de gebruiker want je plakt gewoon de url in het veld en het forum lost het voor je op.

De kans dat iemand een link wil posten naar een Youtube of afbeelding is vrij klein en anders kunnen ze altijd nog de [ url] tag gebruiken

[Reactie gewijzigd door BarôZZa op 23 juli 2024 11:08]

[crisp]

We gebruiken al oEmbed voor o.a. een aantal videoproviders en soundcloud en willen dat dan ook voor twitter/instagram gaan gebruiken. Waarschijnlijk in eerste instantie dan wel met een [embed]-tag omdat anders de impact wel erg groot wordt ([video] en [audio] worden dan waarschijnlijk aliassen van [embed]).

[BarôZZa]

Zijn er wel plannen om het puur op de url te doen? Want de embed tag lost het nog niet op dat het met name op mobiel bij Quick Reply erg onhandig is omdat je dan ubb codes moet intikken.

Als programmeur moet ik trouwens zeggen dat het een leuke feature was om te bouwen (ook dankzij de impact ivm vele oude posts en caches), dus misschien is dat een troost en een aanmoediging

[crisp]

Daar zijn vziw geen plannen voor, maar je zou het in Mooie Features kunnen aandragen als feature

[Reactie gewijzigd door crisp op 23 juli 2024 11:08]

[Bosmonster]

Dat zou wel een voordeel zijn idd in het gebruikersgemak. Neem bijvoorbeeld Slack of iMessage. Als ik daar een url in gooi, weet hij er (bijna) altijd wel een mooie embed van te maken.

[Reactie gewijzigd door Bosmonster op 23 juli 2024 11:08]

[vosManz]

De kans dat iemand een link wil posten naar een Youtube of afbeelding is vrij klein en anders kunnen ze altijd nog de [ url] tag gebruiken

Het is misschien persoonlijke voorkeur, maar ik vindt die embeds juist vaak erg irritant. Zeker op een forum als dat van Tweakers zie ik liever linkjes dan embeds, tenzij een embed echt meerwaarde heeft boven een link (en dat is naar mijn mening zelden).

Ik heb al regelmatig sites gezien waarbij een embed niet correct werd weergegeven (vreemde afmetingen, extra frame waardoor het filmpje niet helemaal zichtbaar was), automatisch begonnen af te spelen met 3 tegelijk, of zelfs sites die zo vrij zijn om bijvoorbeeld de controls van YouTube aan te passen, waardoor je die irritante aantekeningen niet uit kan zetten of zelfs niet door kan spoelen in een filmpje van een kwartier.

En dan heb je het inderdaad nog niet eens over tracking gehad. Zo'n preview plaatje van YouTube is leuk, maar tenzij je die zelf gaat hosten kunnen ze je ook daarmee gewoon tracken hoor.

Wat mij betreft mogen ze embeds dus mooi afschaffen, en vervangen door mooie linkjes zodat ik zelf kan bepalen of ik het filmpje/tweet/etc. wil bekijken en getracked wil worden. Een duidelijke (evt. automatisch via oEmbed opgehaalde) titel bij de link is dan natuurlijk wel prettig. Een alternatief zou zijn wat je nu wel eens op bijvoorbeeld de NPO sites ziet, een overlay voor geblokkeerde embeds die je enkel te zien krijgt als je de cookies accepteert, bij voorkeur dan met een link naar het item als je de cookies niet wil accepteren.

[kalikatief]

Ik ben het niet met je eens. Dat eeuwige embedden vind ik juist irritant, en zeker als het de standaard zo nodig moet zijn.

Met linkjes kan ik makkelijk scannen. Ik kan mijn kop houden bij het hoofdpunt van de post.

Met een dozijn youtube en plaatjes embeds wordt de pagina langer en langzamer terwijl ik deze in veel gevallen niet eens wil zien. Het is of weer een screengrab van een bug, of een 'wat doe ik fout', of iemand die will patsen met zijn geweldige nieuwe camera.

Een embed heeft zijn nut wel, maar het moet dan ook echt het onderwerp zijn van de post zelf.

Ik geef bij verre de voorkeur aan een tekst-zware omgeving dan een verdund instagram or pinterest omgevinkje waar alles zo groot en visueel mogelijk moet worden opgeblazen.

[Mystic_Jack]

Bij het embedden van een Twitterbericht of Instagramfoto worden er natuurlijk ook cookies gebruikt van die websites. Hoe werkt dat binnen het forum wat niet openbaar is? Zoals de huiskamer bijvoorbeeld.

[crisp]

Een extern plaatje kan ook al gebruikt worden om cookies te zetten, dus dat werkt feitelijk niet anders. De meeste embeds zijn iframes, dus kunnen in ieder geval niet bij bijvoorbeeld jouw sessie-cookie komen. 3rd-party cookies blokkeren in je browser voorkomt ook dat vanuit dergelijke embeds cookies kunnen worden gezet.

De Twitter embed is echter wel weer een ander verhaal; die wilt dat je een stukje javascript in je pagina include. Dat gaan wij echter (vanuit privacy- en securityredenen) niet doen, dus daar gaan wij zelf een stukje styling voor verzorgen.

[Barryke]

Bij het embedden van een Twitterbericht of Instagramfoto worden er natuurlijk ook cookies gebruikt van die websites.

Ik was voor deze feature, totdat ik dit las. Als je iets embed geef je privacy info (van iedere bezoeker!) weg voor de bezoekers die een embed willen zien zonder te moeten klikken. Eigenlijk wel een goede reden om dit juist niet te doen..

Als het er toch in komt, is een "show embeds" knop bij zo'n link misschien wel verstandig.
Of als je het toch standaard wil aanzetten, een profiel setting onder privacy waar je "verberg embeds (van x, y, z)" mag aanvinken.

[HollowGamer]

Het fijne van (meer) Twig is dat je ook aan caching kan doen, dat zal zeker de snelheid en server load ten goede doen.

Het lijkt ook allemaal te verschuiven naar een losse API/REST en een static frontend zoals Vue, Angular, react, etc. met webpack. Wat is jullie kijk hierop? Gebruiken jullie hier al iets van? Zijn er plannen voor?

Het is wel soms om gek van te worden; Twig wordt bijvoorbeeld nu weer gezien als 'oud', terwijl het nog prima werkt en wordt onderhouden.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 11:08]

[Sebazzz]

Het lijkt ook allemaal te verschuiven naar een losse API/REST en een static frontend zoals Vue, Angular, react, etc. met webpack. Wat is jullie kijk hierop? Gebruiken jullie hier al iets van? Zijn er plannen voor?

Laten we de vraag omdraaien: Wat is de meerwaarde van een SPA tegenover een snelle geoptimaliseerde MPA zoals deze website?

[Misha]

Een SPA zou je wat flexibeler maken voor je strategie met bijv mobile apps. Het is daarvoor erg handig dat je front-end en backend niet hard gekoppeld aan elkaar zijn. Maar gezien de noodzaak voor een mobile app die wezenlijk wat anders doet dan de website er voor Tweakers niet echt is, is dat niet direct een voordeel in de context van Tweakers.

Ik mis dergelijke nuanceringen vaak wanneer discussies over techniek gaan. Leuk, een lijstje van de voor- en nadelen, maar wat betekenen ze in de context van het product zelf

[s.stok]

Ik denk dat een SPA vooral een meerwaarde heeft bij een applicatie waar je veel verschillende taken verricht zoals een Banking applicatie, Belasting aangifte, huis zoeken, online chat, en al. Voor een Nieuwsite (wat Tweakers toch vooral is) is een SPA wat zwaar en het waarschijnlijk niet waard om te gebruiken, hoogstens een paar React/Angular onderdelen waar dit handig is (zoals Galerij).

Een SPA heeft ook allerlei valkuilen zoals memory leaks.

[Rooieduvel]

Kan aan mij liggen, maar volgens mij werkt de optie [list] en [jump] niet meer bij product reviews?

Edit: Jump werkt wel, list niet meer...

[Reactie gewijzigd door Rooieduvel op 23 juli 2024 11:08]

[crisp]

We gaan er naar kijken

Edit: @Rooieduvel @Anonymoussaurus Bij deze gefixed

[Reactie gewijzigd door crisp op 23 juli 2024 11:08]

[Anonymoussaurus]

Same here. Wilde net een list gebruiken hier: Anonymoussaurus in 'nieuws: EvLeaks toont render van Samsung Galaxy Note 9' maar werkte ook niet. Er gebeurd dan simpelweg niets (UBB code is wel gewoon zichtbaar). Kan je mij taggen ofzo als het is opgelost? Thanks .

[Rooieduvel]

Overigens doet de [ * ] het ook niet.
En ik merk het wel!

Edit: Thanks @crisp !

[Reactie gewijzigd door Rooieduvel op 23 juli 2024 11:08]

[Anonymoussaurus]

Thanks!

[Technomania]

Kan dit er mee te maken hebben dat de Populaire tweakblogs niet meer direct zichtbaar zijn op de FP zonder op "Meer tweakblogs" te klikken?

(Win10+FF)

[Femme]

Er zat een bugje in de logging van views van de tweakblogs. Inmiddels is dat opgelost. Het loggen moet nu echter weer op gang komen en het duurt event voordat blogposts het minimum aantal views voor een populaire tweakblog hebben bereikt. Daar zit een ondergrens aan.

[Technomania]

Bedankt voor de toelichting!

[Mitchell]

Zijn er plannen om de nieuwe parser open source te maken? (u)bb-code parsers zijn een enorme PITA en ik zoek altijd nog naar een goede om te gebruiken voor mijn eigen forum. Maak op dit moment gebruik van `vanilla/nbbc` met custom rules, maar dat werkt toch niet altijd even lekker.

[WhiteDog]

T.net gebruikt zelf veel open source# maar geven ze ook wat terug?

[The_Worst]

Crisp heeft JSMin+ uitgebracht als open-source. Deze wordt zelfs gebruikt bij MediaWiki.

[justVR]

Wie kan mij dependency injection in eenvoudige taal uitleggen?

[s.stok]

Heel simpel gezegd: Met dependency injection word de afhankelijkheid van externe classen geregeld door middel van injectie ipv van dat de Class deze zelf regelt.

Stel je hebt een ClassA die een logger nodig heeft, ClassA kan die logger zelf aanmaken, maar daardoor ben je dus altijd afhankelijk van die implementatie, je kan dit niet wijzigen zonder ClassA zelf aan te passen.
Dit noemen we ook wel een hard-coupling (horde koppeling). Een singleton (single instance) gebruiken om altijd de zelfde Logger te krijgen is zoon voorbeeld.

Met dependency injection (DI) geef je de Logger mee aan de class (constructor or via een method), en je zelf bepalen welke Logger ClassA meekrijgt, de controle word bij de gebruiker van de class gelegd in plaats van dat de class dit bepaald officieel heet dit de dependency inversion principle.

Dit heeft voordeel dat je de class kan hergebruiken met verschillende logger implementaties, en maakt testen makkelijker omdat je bij elk object geen rekening hoeft te houden met externe factoren.

Dit is meest simpele manier hoe ik het kan uitleggen, maar er zijn op internet tal van Artikelen te vinden hierover. https://stackoverflow.com/a/130862/9256768

[Verwijderd]

Ziet er weer goed uit allemaal

[Jolke]

Mooie update weer. Goed bezig, Tweakers!

[CH4OS]

Ben benieuwd wat uit de community pick omhoog gaat komen, al vrees ik met grote vrezen dat meer integratie met socials (en dus meer externe tracking) het gaat worden, waar ik eigenlijk niet echt op zit te wachten.

[AW_Bos]

Volgens mij is Tweakers er juist op tegen. Kijk eens naar de FB-likes, en de share linkjes?
Allemaal uit eigen code, zonder tracking en dergelijke. Ook Twitter en Instagram kunnen prima met oEmbed veilig worden gebruikt om te embedden.