WIP: setup astro as a test #13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "astro"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Eksemple på oppset av astro for nettsiden.
Syns ikke dette fikk så godt frem hvordan Astro funker. Jeg ryddet litt opp i det og la til litt ekstra funksjonalitet.
Jeg er ikke den største fan'en av at vi bruker markdown for å lage sider som ikke er typ en bloggpost, styremøter eller noe. Det er ofte nyttig å integrere visuelle komponenter inn i innholdet for å få frem poenget sitt bedre.
Så jeg la til MDX med
npx astro add mdx. Personlig er jeg stor fan av .mdx. Skal vi lage landingssider om tjenestene våre så er jeg helt sikker på at det har det godt av å ha litt mer enn bare en vegg av tekst i markdown.Og så lagde en form komponent. Merk at det er vanilla CSS og stylen vi definerer i MemberForm scopes til den komponenten.
Og jeg importerte og la til
<MemberForm />i markdown filen.Edit: Jeg er fullt klar over at et skjema her ikke gir helt mening.
Hvis det er slik dere vil utvikle websiden så vil jeg overlate arbeidet til dere og ønsker dere lykke til. Dette kommer ikke jeg til å ta del i.
Jeg la til Astro sin content collection for å vise hvordan en tjeneste indeks kan se ut. Åpenbart KI, poenget er å showcase Astro funksjonalitet. Dette er en killer feature, har Hugo noe i nærheten?
@hornwitser wrote in #13 (comment):
Jeg har ikke bestemt meg om jeg foretrekker Astro eller Hugo, men jeg lurer på hvorfor du er så bestemt imot Astro?
Astro som teknologi og system er isolert sett ok. Problemet er at Astro har mange utvidelser, plugins, og ferdige løsninger som frister veldig å bare legge til med en
npm install. Dette fører til at man lett legger til en modul til, og enda en, og enda en. Spesielt i et sammarbeidsprosekt med mange bidragsyttere som alle vil ha sin egen ting lagt til så vokser dette veldig fort til et skjørt og komplisert virvar.Det tok ikke lange tiden før Astro demoen her plustselig hadde
mdxogså. Kompleksitet er fienden til stabilitet og enkel vedlikehold. Skal man klare å holde prosjektet vedlike over lang tid så man må være sterkt kritisk til enhver avhengihet og komplisert løsing man legger til. Det er hip å ha det seneste og feteste bibliotekene i prosjektet, men det er desverre ikke like kult å bygge kjedelige, stabile, enkle, lette, og dumme løsninger.Med andre ord. Det jeg ser er at Astro kommer til å tiltrekke seg veldig mye press på å legge til atter mer komplisert kode og bibliotek til prosjektet, og at den som ønsker å ta ansvar for å holde kompleksitet nede vil ha en sisyfisk oppgave med å overbevise de andre at ikke er greit å legge til «bare en til npm pakke».
Jeg er ikke uenig. Jeg ønsker færrest mulig pakker og dependencies også. Men det er en forskjell på å bruke en official extension av Astro med helt industristandard teknologi som ikke går noe sted (mdx) og det å legge til one-off javascript skrot. Det er også noe litt annerledes med pakker i build-stage vs. lastet straight inn i browseren til medlemmer.
MDX har jeg hatt svært god erfaring med når vi skrev dokumentasjon og læringsmateriale for front-end kurset IN5320 på UiO. At de som skriver en tjenesteside eller bloggartikkel kan legge til kode/komponenter rett i markdownen er verdifullt. Det skaper både consistency i templatingen for utviklere da vi kan tvinge frem markdown, men det gir også fleksibilitet til publisentene til å legge til litt mer detaljer. Nettsiden vår er ikke bare for utviklere, det er for innholdsprodusenter som ønsker å kommunisere og systemansvarlige å dokumentere systemene sine. De må vi designe for også.
Uten å være sikker på det tyder det på at en tilsvarende publiseringsflyt i Hugo bruker shortcodes? Jeg syns ikke det ser like ergonomisk ut (men det er nok en preferansesak).
Jeg anser to andre offisielle pakker som aktuelle:
Jeg blir gjerne med på et moratorium på flere pakker og strenge prosesser rundt det å legge dem til. Det høres hensiktsmessig ut.
Jeg lekte litt mer med dette.
Astro er content collections. De har identifisert at det virkelig handler om innholdet. Bygger man scaffoldingen rundt innholdet så får man en ganske bra publishing løsning.
Final notes:
@hornwitser wrote in #13 (comment):
Jeg tror hvis vi er i den luksussituasjonen at for mange vil bidra med for mye, så er det også noe bra. Enn så lenge føler jeg at vi har alt for få folk som faktisk gjør noe - kanskje derfor jeg ikke er så redd.
Jeg er litt enig med Alex i at jeg tror med retningslinjer skal det være mulig å styre unna for mye kompleksitet og npm pakker for alt mulig unødvendig, men jeg kan selvfølgelig da feil.
Fant noen artikler som Hugo med web components, men har ikke hatt tid til å lese gjennom. Kunne ellers kanskje vært et alternativ til shortcodes?
View command line instructions
Manual merge helper
Use this merge commit message when completing the merge manually.
Checkout
From your project repository, check out a new branch and test the changes.