NE­OS CMS: AL­LES NEU MIT RE­ACT

SCREENGUIDE - - Events - TExT: Bas­ti­an Heist

„Com­ple­te re­wri­tes are to­xic. From a pro­duct ow­ner’s view, it’s a com­ple­te no go.” Solch deut­li­che Ab­leh­nung er­fuhr der Vor­schlag ei­ner Neuim­ple­men­tie­rung der Be­nut­zer­ober­flä­che des Con­tent-Ma­nage­ment-Sys­tems Ne­os mit Re­act in der Com­mu­ni­ty. Zwei Jah­re spä­ter ist der Re­wri­te fer­tig und ein Vor­zei­ge-Fea­tu­re von Ne­os 4.0.

Kom­plet­te Neuim­ple­men­tie­run­gen sind im­mer mit Ri­si­ken ver­bun­den. Selbst gro­ße Soft­ware­un­ter­neh­men scheu­en den Auf­wand. Der Ab­bau tech­ni­scher Schul­den und die Nut­zung mo­der­ner Tools recht­fer­ti­gen oft nicht die ho­hen Kos­ten. Das ist ins­be­son­de­re dann der Fall, wenn die be­tref­fen­den Ent­wick­ler nur in ih­rer Frei­zeit und un­be­zahlt tä­tig sind. Das Co­re Team des Con­tent-Ma­nage­ment-Sys­tems Ne­os hat sich trotz­dem ge­traut, die Be­nut­zer­ober­flä­che sei­nes CMS in Re­act und Re­dux voll­stän­dig neu zu schrei­ben. Re­act ist ei­ne Ja­vaS­cript-Li­bra­ry für kom­po­nen­ten­ba­sier­te Front­end-Ent­wick­lung. In Ver­bin­dung mit dem Zu­stands-Sto­re Re­dux bil­det es den Kern vie­ler mo­der­ner We­b­an­wen­dun­gen. Es zahl­te sich aus: Selbst Re­act-Er­fin­der Dan Abra­mov lob­te das Team für sei­ne Ent­schei­dung (Abb. 1).

KOM­PLE­XE OBER­FLÄ­CHE FÜR IN­LI­NE EDIT­ING

War­um braucht ein CMS über­haupt ei­ne Ja­vaS­cript-UI? Be­lieb­te CMS wie et­wa Word­press kom­men mit ei­ner Rei­he von Text­fel­dern mit Rich-Text-Funk­tio­na­li­tät aus. Ne­os ver­folgt hier je­doch ei­nen an­de­ren An­satz. Textin­hal­te wer­den kon­se­quent in­li­ne, al­so di­rekt im je­wei­li­gen Con­tent und Lay­out der Web­sei­te, be­ar­bei­tet – sie­he auch die Box „Ne­os im Über­blick”. Da­zu wird die Web­sei­te selbst in ei­nem Con­tai­ner ge­la­den, in und um den her­um Ne­os per Ja­vaS­cript die Be­di­en­ober­flä­che für Au­to­ren plat­ziert. Die­ses Kon­zept er­for­dert deut­lich mehr Pro­gramm­lo­gik, als le­dig­lich HTML- oder Rich­text-In­hal­te in ei­nem Text­feld zu be­ar­bei­ten. Be­reits mit dem Re­lease von Ne­os 1.0 – da­mals TYPO3 Ne­os – im De­zem­ber 2013 war das In­li­ne Edit­ing Kern­be­stand­teil und of­fen­kun­digs­te In­no­va­ti­on des neu­en CMS. Dem­ent­spre­chend wur­de die Be­nut­zer­ober­flä­che mit den Tools von da­mals um­ge­setzt. Ei­ne „Va­nil­la JS”-Lö­sung, al­so ei­ne Im­ple­men­tie­rung oh­ne Frame­work, war da­mals aber noch we­ni­ger als heu­te ei­ne va­li­de Op­ti­on; da­zu war das Ja­vaS­cript-Öko­sys­tem zu we­nig aus­ge­reift. Man setz­te von Be­ginn an auf Tech­no­lo­gi­en wie Em­ber 1.0, den Alo­ha Edi­tor, Re­qui­reJS so­wie VIE und Crea­te.js.

Ge­nau hier lag al­ler­dings das Pro­blem: Die Viel­zahl und Kom­ple­xi­tät der ver­wen­de­ten Li­bra­ries führ­ten sehr schnell da­zu, dass die Ent­wick­lungs­ge­schwin­dig­keit sank. Hin­zu kam, dass der ver­wen­de­te Rich-Text-Edi­tor Alo­ha von sei­nen Ent­wick­lern ein­ge­stellt wur­de, so­dass ei­ne Al­ter­na­ti­ve un­um­gäng­lich war.

RE­WRI­TE ODER UP­GRADE?

Die Mit­te 2015 be­gon­ne­ne Dis­kus­si­on in der Ne­os-Com­mu­ni­ty fo­kus­sier­te sich sehr bald auf zwei Op­tio­nen: Ein Teil der Ent­wick­ler fa­vo­ri­sier­te ei­ne kom­plet­te Neuim­ple­men­tie­rung mit Re­act, wäh­rend ei­ne an­de­re Grup­pe für ein gra­du­el­les Up­grade der be­ste­hen­den Lö­sung auf Em­ber 2.0 plä­dier­te. An­gu­larJS wur­de nicht in Be­tracht ge­zo­gen – das Team war von sei­ner Phi­lo­so­phie nicht über­zeugt, zu­dem hat­te kein Kern­ent­wick­ler tie­fe­re Er­fah­run­gen da­mit. Im No­vem­ber 2015 traf das Team schließ­lich die Ent­schei­dung, das Up­grade-Pro­jekt auf Em­ber 2.0 zu star­ten. Es stell­te sich je­doch schnell her­aus, dass die Viel­zahl der Li­bra­ries und die Kom­ple­xi­tät des be­ste­hen­den UIs ei­ne Neuim­ple­men­tie­rung gro­ßer Tei­le des Co­des not­wen­dig mach­ten. Schließ­lich soll­te die Ober­flä­che beim Up­grade tech­nisch ver­schlankt und mit ei­nem neu­en Rich-Text-Edi­tor er­gänzt wer­den. Im Ja­nu­ar 2016 stell­te ein klei­nes Team da­her ei­nen Re­act-Pro­to­typ auf die Bei­ne, der die Wen­de in der Dis­kus­si­on brach­te. In nur we­ni­gen Ta­gen pro­gram­mier­ten die Ent­wick­ler ei­nen be­trächt­li­chen Teil der Ne­os-Ober­flä­che in Re­act nach – der Rest des Teams war schnell über­zeugt. Nach ei­ner er­neu­ten Ab­stim­mung be­gann das Pro­jekt „Re­act-Re­wri­te” im Fe­bru­ar 2016 of­fi­zi­ell. Die In­ter­ak­ti­ons­mus­ter in Open-Sour­ce-Pro­jek­ten tre­ten hier sehr deut­lich zu­ta­ge. Ob­wohl die fast ein hal­bes Jahr an­dau­ern­de, tech­ni­sche Dis­kus­si­on vie­le Gr­und­fra­gen er­ör­ter­te, war letzt­lich ein funk­tio­nie­ren­der Pro­to­typ not­wen­dig, um den Groß­teil der Com­mu­ni­ty zu be­geis­tern und das Pro­jekt zu un­ter­stüt­zen.

TECH­NI­SCHE VOR­ZÜ­GE VON RE­ACT & RE­DUX

Ei­ne gan­ze Rei­he tech­ni­scher Grün­de spra­chen deut­lich für ei­ne Um­set­zung mit Re­act und Re­dux – al­len vor­an das Ar­chi­tek­tur­pat­tern „Da­ta Down, Ac­tions Up”. Wäh­rend Em­ber 1.0 mit so­ge­nann­ten „Two-Way-Bin­dings” Da­ten zwi­schen UI-Kom­po­nen­ten aus­tauscht, lau­fen Än­de­run­gen im Da­ten­mo­dell in Re­act/Re­dux über se­man­tisch mo­del­lier­te Events. Die­se „Ac­tions” ge­nann­ten Ja­vaS­cript-Ob­jek­te ent­hal­ten In­for­ma­tio­nen zu Typ und In­halt der aus­ge­lös­ten Be­nut­zer­ak­ti­on. Die UI-Kom­po­nen­ten lö­sen die­se Ac­tions (z.B „INCREMENT_ COUNTER”) auf ei­ne Be­nut­zer­ein­ga­be hin aus. Ac­tions wer­den von ei­nem „Re­du­cer” ver­ar­bei­tet. Da­bei han­delt es sich um ei­ne Funk­ti­on, die den ak­tu­el­len UI-Zu­stand (Sta­te) als Ja­vaS­crip­tOb­jekt so­wie die Ac­tion ent­ge­gen­nimmt und dar­aus ei­nen neu­en Sta­te er­zeugt. Die­ser wird an ei­nen zen­tra­len Sto­re wei­ter­ge­reicht, der wie­der­um die UI-Kom­po­nen­ten (Views) über die Än­de­run­gen be­nach­rich­tigt. Dar­auf­hin zeich­nen sich die­se in­kre­men­tell neu, um et­wa die Er­hö­hung ei­nes Zäh­lers auf ei­nen But­ton-Klick hin ab­zu­bil­den. Der uni­di­rek­tio­na­le Da­ten­fluss, der da­durch ent­steht, er­leich­tert das Ver­ständ­nis der An­wen­dung und das De­bug­ging enorm. Hin­zu kommt, dass mit JSX in Re­act ei­ne Mark­up-Spra­che für kom­po­nen­ten­ba­sier­te Ent­wick­lung zur Ver­fü­gung steht. Auch das her­vor­ra­gen­de Ent­wick­ler-Too­ling so­wie die ge­rin­ge Grö­ße und gu­te Kom­bi­nier­bar­keit der ein­zel­nen Li­bra­ries spre­chen für das Re­act-Öko­sys­tem. In Sum­me steht Ent­wick­lern ei­ne sehr sta­bi­le, nach­voll­zieh­ba­re Ent­wick­lungs­um­ge­bung zur Ver­fü­gung. Vor al­lem Bugs, die zu­vor durch asyn­chro­ne Ak­tio­nen, wie et­wa das Nach­la­den von Da­ten vom Ser­ver, ent­ste­hen, las­sen sich in der Re­act-Um­ge­bung sehr gut be­he­ben. Se­bas­ti­an Kur­fürst, ei­ner der Haupt­ent­wick­ler der neu­en Ober­flä­che, for­mu­liert es so: „Für die neue Ne­os-UI nut­zen wir Re­act und Re­dux, da wir hier­durch ei­ne ho­he Sta­bi­li­tät, Ska­lier­bar­keit und Er­wei­ter­bar­keit ge­währ­leis­ten kön­nen. Re­dux er­mög­licht es uns wei­ter­hin, die Per­for­mance der An­wen­dung sehr gut zu op­ti­mie­ren, was für ei­ne UI die­ser Grö­ße und Kom­ple­xi­tät un­er­läss­lich ist.”

DIE REA­LI­SIE­RUNG

Be­sag­te Grö­ße und Kom­ple­xi­tät war die wich­tigs­te tech­ni­sche Her­aus­for­de­rung für die Ent­wick­ler des neu­en UI. Die Schnitt­stel­le zum Ba­ckend durf­te nicht zu stark ver­än­dert wer­den, da die Kom­pa­ti­bi­li­tät mit der al­ten Be­nut­zer­ober­flä­che er­hal­ten blei­ben muss­te. Da­ne­ben brauch­te das Team Lö­sun­gen, um Mehr­spra­chig­keit, Er­wei­ter­bar­keit, The­ming und Per­for­mance der Re­act-An­wen­dung si­cher­zu­stel­len. Die Fle­xi­bi­li­tät des Re­act-Öko­sys­tems war da­bei Se­gen und Fluch; aus der Viel­zahl der Mög­lich­kei­ten muss­ten die Pro­gram­mie­rer die pas­sends­ten aus­wäh­len – oder gleich ei­ge­ne Kon­zep­te ent­wi­ckeln, wie im Fal­le der Er­wei­ter­bar­keit.

Abb. 1: Re­act-Er­fin­der Dan Abra­mov lob­te die Ent­wick­ler des Ne­os UI für ih­re Ver­wen­dung des Zu­stands­con­tai­ners Re­dux [goo.gl/PjGA92].

Abb. 2: Das Flux-Pat­tern ist die Grund­la­ge von Re­act/Re­dux-Ap­pli­ka­tio­nen.

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.