Inlägg

Inlägg som ChrisDev har skrivit i forumet
Av ChrisDev

Om det är för jobb, satsa på något mycket utbrett.
Föreslår C# och JavaScript (snarare TypeScript).
Man är glad att det är typat när det är större system/kodbas.

Av ChrisDev

För småprojekt är det väl lättare att köra typ Render eller dyl. Allt funkar typ automagiskt med certs, deploy etc.

Av ChrisDev

Själv föredrar jag Azure & Azure DevOps som nämnts men om du är rädd för oväntade kostnader så kan du ju testa GitLab i kombination med Render. GitLab för CI/CD (med YAML) och Render för gratis hosting (stödjer Node, Docker etc).

Av ChrisDev

Nu är jag ingen expert på React och det finns nog många sätt men du kan ha isLoggedIn i app och med hjälp av den styra med routern vad man har åtkomst till.

Är man inte inloggad så <Navigate to="login" /> annars rendera önskad sida/komponent.

Av ChrisDev
Skrivet av Verdurakh:

React är ju typ pure js (eller jsx) där du skriver din html inne i din js kod och blandar js och html vilket för många som kommer från vanilla html/css/js kan se mysko ut och vara svårt att förstå innan man vänjer sig vid det.
Svelte

<script> const animals = ["Dog", "Bird", "Cat", "Mouse", "Horse"]; </script> <ul> {#each animals as name} <li>{name}</li> {/each} </ul>

React

const animals = ["Dog", "Bird", "Cat", "Mouse", "Horse"]; return ( <ul> {animals.map((name) => ( <li>{name}</li> ))} </ul> );

I detta tycker i alla fall jag att svelte är närmare hur man annars skriver html/js/css även om den introducerat ett eget {#each} element så är det tydligt för många vad det gör. Tycker att det ser väldigt rent och prydligt ut och ger mindre syntaxkomplexitet, men alla tycker ju såklart olika. Jag använder båda

Ifall man lärt sig JS innan man ger sig in i React/Svelte (vilket man förmodligen borde) så kommer ju React-exemplet se mindre mysko ut. Min poäng var ju att React är närmare JS än Svelte, inte vilket av dem som ser "renast" eller enklast ut 🙂

Av ChrisDev
Skrivet av Verdurakh:

Svelte skulle jag säga är det som är trevligast att jobba med, mest för att det är mer ren htmll/javascript jämfört med react etc.

Alla reactutvecklare jag introducerat det för har konverterat om det inte finns krav från arbetsplatsen eller liknande, jobbmässigt är det tyvärr fortfarande mycket react.

Hm, Svelte kör t ex med påhittad each-syntax medan du kör map i React för att slänga ut en lista eller dyl. React känns väl överlag ganska JS-nära.

Av ChrisDev
Skrivet av Dockman:

Håller med dig! Men det kostar skjortan! Kanske i framtiden om det går bra för sajten. SSL är bra grejor, men kostar en del.

Vill dock att folk skall kunna ha roligt gratis, utan annonser och detta gick att fixa med gratis hosting. Har du några synpunkter på designen då? Vad kan förbättras?

Tacksam!

Nu är jag inte insatt i färdiga forum men ett demo/lågfrekvent besökt forum kan hostas gratis och en domän med SSL-cert kostar inte många kronor. Designen ser ut som ett vanligt föråldrat forum som någon nämnde.

Av ChrisDev

Känns väl alltid lite trevligare och mer seriöst med ett SSL-certifikat och en mer standard-toppdomän, så det är väl ett/två tips

Av ChrisDev

Jag fick jobb strax före 35, läste YH men hade suttit en hel del ett par år före det. Känner nu att jag hellre hade börjat när jag var typ 20 (hobbykodade lite som pojkspoling men blev inget seriöst med det). Det tar lång tid att bli bra på detta och personligen kände jag att det åldersmässigt var gränsfall, hade nog inte gett mig in i det efter 40.

Sen beror ju mycket som sagt på ens egen inställning och intresse samt hur livet ser ut i övrigt.

Av ChrisDev

Som sagt, med tanke på senaste recensionen på TrustPilot hade i alla fall inte jag blivit så sugen...
https://se.trustpilot.com/review/backmarket.se

Av ChrisDev
Skrivet av WebbkodsLärlingen:

Ja, det där med Web API:er är intressant för i början av JS så är man (iaf jag) så van att koda för JS-kod som körs i webbläsaren att man inte inser att `document` tillhandahålls av webbläsaren och inte JS-språket i sig. Så när man då hoppar över till exempelvis NodeJS som är JS för backend så finns inte `document` för den tillhandahålls helt enkelt inte av NodeJS. Även console-klassen som körs i NodeJS gäller för terminalen i ens IDE och inte i webbläsaren trots att man kanske surfar in på en webbplats som tillhandahålls via NodeJS. Det måste då vara JS-filen som läses in av webbplatsen som NodeJS tillhandahållit som kan få console-klassen där då att skriva ut i webbläsarens egen konsol.

Det finns väldigt många små - men avgörande viktiga - detaljer i programmering som gör att man kan fastna på små saker. T.ex. tog det ca ett halvår innan det koppla för mig om skillnader mellan array-liknande arrayer och "riktiga" arrayer. Innan dess så trodde jag att det bara fanns arrayer och det var det så jag fattade inte varför jag inte kunde använda array-metoden forEach på alla mina document.QuerySelectorAll-lagrade variabler!

Och då ska vi inte ens prata om "this" som pekar på nuvarande objekt där nuvarande objekt beror på varifrån det körs och hela det är sitt eget "periodiska system" att hålla koll på! Välkommen att rätta mig i allt jag möjligen faktamässigt har sagt fel nu så inte andra oxå lär sig fel som jag kanske har gjort!

Mvh,
WKL.

forEach funkar.
https://imgur.com/a/xsCayPw

Av ChrisDev
Skrivet av Terzom:

Nu är jag inte häller någon expert men kan visa ett exempel vad gällande exempelvis addEventListener.

Allt i Javascript är funktioner och objekts. cards använder sig av querySelectorAll som spottar ut en Array. Array har då en drös med prototyper, som är funktioner som finns tillgängliga, som exempelvis forEach som du använder. Det går till exempelvis inte att göra cards.toString() för den funktionen finns inte för Arrays. Medans om du hade gjort querySelector, så hade toString funkat men inte forEach.

Så vad du har gjort är att ha ropat på en annan function som heter addEventListener, som tar 2 parametrar, och beroende på de, så return'ar den ett objekt som du kan leka med.

Ett kodexempel så kanske det blir mer förståligt:

const element = document.querySelector('div'); element.__proto__.myCustomEvent = function(type, fn) { let myEvent = { enMassaOlikaSaker: 'obj, fn, stuff', } return fn(myEvent) } element.myCustomEvent('click', function(myEvent) { console.log('myEvent:', myEvent) // { enMassaOlikaSaker: 'obj, fn, stuff' } })

querySelectorAll returnerar en NodeList som liknar en Array, den har forEach men inte t ex map.
Kan enkelt göras om till array dock.

För övrigt är det nog många som inte vet eller tänker på att querySelector och dyl inte är JavaScript utan en del av Web API.

Av ChrisDev

querySelector/querySelectorAll brukar väl anses the way to go i de flesta fall. Som nämnts returneras en NodeList som man kan göra om till en array vid behov med Array.from eller [...document.querySelectorAll]

Av ChrisDev
Skrivet av Oskaro123:

Tack för tipsen, ska prova det någon av de, man lär ju inte behöva betala lika mycket när man använder en sån tjänst mot typ ett webhotell heller

De jag nämnde har i alla fall gratisvarianter och räcker gott för demoprojekt eller små projekt.

Av ChrisDev
Skrivet av Oskaro123:

Alright, ja det får nog bli att deploya på något annat ställe istället. Tack för hjälpen!

Testa render.com eller Netlify, eller en Azure Static Web App.

Av ChrisDev

React om du vill ha mer frihet och vilda västern. Angular om man gillar det mer opinionated och om du gillar använda klasser/OOP, dependency injection osv samt vill ha mer "batteries included".

Som påpekats så är React förmodligen bättre rent jobbmässigt och en del har ju gått ifrån Angular till just React. Sen vet jag även exempel på folk ifrån min utbildning som fick jobb just för att de kunde lite Angular och det finns inte lika många som kan det eller är sugna på det numera antar jag.

Av ChrisDev

Skaffa ett Azure-konto och labba med gratis databas (Azure SQL/MSSQL) och gratis hosting, CI/CD i Azure DevOps etc. Labba lite med Entity Framework som är standard ORM för de flesta. Vad gäller själva språket C# så är det mycket trevligare än PHP och JavaScript i min värld i alla fall 🙂

Av ChrisDev
Skrivet av kwame:

Självklart finns det, du låter bara okunnig om du påstår något annat. Testa jobba med frontend för ett avancerat affärssystem så kan jag lova att du kommer få det svårt. I de fallen kan frontend vara extremt komplext. Det svåra är inte att få utseendet perfekt, utan snarare att få alla komponenter att interagera med varandra och innehållet är allt annat än statiskt, vilket gör att det blir avancerad logik man behöver få ihop på ett hållbart/solid sätt.

Jobbar delvis med frontend och vet att det kan vara komplext, har inte sagt annat. Däremot finns ju inte lika mycket best practices där som i backend.

Av ChrisDev
Skrivet av boogey:

Bland gamla kollegor och vänner verkar det fortfarande som det anställs, även om det kanske börjar komma lite sparkrav och en del företag har gått över till "konsultväxlingar".

Oavsett så kan det vara ganska segt med jobb överhuvudtaget i Sverige och det tar tid, mitt första jobb var också en seg affär, så jag tycker ni ska ligga på och fortsätta söka. Vissa företag kommer att nobba er för att ni saknar en längre formell utbildning och inte har så mycket erfarenhet, så är det bara. Får ni in en fot och får jobba så är det där helt irrelevant sen, folk har alla möjliga bakgrunder i det här yrket.

Sen vill jag påstå att backend ändå är en mycket större arbetsmarknad, .Net eller Java + Spring. Många större företag förstår inte riktigt hela biten med frontend och anställer bara "fullstack"-utvecklare, d.v.s. backend-utvecklare som kan fuska ihop lite frontend som i bästa fall ser respektabel ut utåt sett men ligger långt från best practice om man tittar på själva koden .

Finns det best practices i frontend? 😁
I alla fall så känns .NET eller Java som du säger som ett ganska bra spår sett till jobbmarknaden. Många snöar väl in på grejer som inte används lika mycket IRL som på YouTube och då blir det ju svårare. En del anser ju att .NET och Java är gammalt och gubbigt, men då får man sitta med MERN eller Flask som knappt någon efterfrågar i jämförelse 🙂

Av ChrisDev
Skrivet av kelthar:

Jag föredrar commandline om jag inte vill kolla branchar, så vi är nog från två olika håll.

Förmodligen. Command line Git var det enda jag kunde (nåja, basics iaf) i början men sen insåg jag att det bara var omständigt när det finns smidigt GUI för det. 🙂
Särskilt i jobbsammanhang med så många branscher osv.