allan ebdrup bloghoved ny

JavaScript: Lær nogle seje tricks.

Jeg er snublet over sitet codewars.com og det er vanedannende. Det har på få dage gjort mig til en bedre JavaScript-programmør. Dels fordi jeg har lavet små algoritmer, jeg ellers ikke laver så meget af til hverdag, og dels fordi jeg har kigget andre dygtige programmører over skulderen.

Codewars går i alt sin enkelhed ud på, at man får stukket små programmøringsopgaver ud, som man så løser. Når man har løst sin opgave får man de andres, nogle gange geniale, løsninger at se.

Der er selvfølgelig et ranking-system, up-votes af løsninger, diskussioner og man kan også lave sine egne opgaver, kaldet kataer.

Konkrete tricks

Her er nogle eksempler på JavaScript-tricks. Nogle kendte jeg i forvejen og nogle har jeg lært eller fået genopfrisket på codewars.

Du skal være opmærksom på, at hvis det skal virke i alle browsere skal du nok have fat i en shim. Alle tricks virker out-of-the-box i node.js.

Hvis du gerne vil checke en http-responskode, kan du gøre det med:

if (/2\d\d/.test(response.statusCode)){
    //statusCode er i 200-range
}

Når du gerne vil bruge nogle af de nye funktioner på arrays, som forEach, indexOf, map, reduce, filter, every, some, find osv. Så virker de ikke på et array hvor du bare angiver længden i new. Hvis du for eksempel skal lave et array med værdierne 0 til 9:

 //VIRKER IKKE
var a = new Array(10).map(function (value, index){
    return index;
});
//a er lig [undefined, ..., undefined]
//fordi map ikke bliver kørt rigtigt
 
//VIRKER
a = Array.apply(null, new Array(10)).map(function (value, index){
   return index;
});
//a indeholder [0, 1, 2, 3, 4, 5 ,6 ,7, 8, 9]

Hvis du gerne vil filtrere alle falsy værdier (undefined, null, nul (0), tom streng, NaN, false) fra et array, kan du gøre det således:

var a = [undefined, null, 0, '', false, 'test'].filter(Boolean);
// a indeholder nu kun ['test']

Hvis du har en if-sætning, hvor du skal checke om en variabel er lig en af to eller flere strenge, kan du gøre det sådan:

if (['test1', 'test2', 'test3'].indexOf(v) !== -1){
    //v er lig med test1, test2 eller test3
}

Hvis du er rigtig fræk udnytter du at 0 (nul) er falsy. Det vil jeg dog umiddelbart ikke gøre i kode jeg skal vedligeholde, men til codewars er det fint.

if (['test1', 'test2', 'test3'].indexOf(v) + 1){
    //v er lig med test1, test2 eller test3
}

Hvis du vil have den største tal-værdi fra et array, kan du gøre det sådan:

var max = Math.max.apply(Math, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]);
//max er lig 9

Hvid du vil lave en streng om til et array af de enkelte tegn, kan du gøre det sådan:

var a = 'test'.split('');
//a er lig ['t', 'e', 's', 't']

Hvis du vil lave en if-sætning, hvor koden kun kører hvis et array har indhold, kan du gøre det med:

//a er en variabel med et array
if (a.length){
    //a har indhold
}

Der er mange andre tricks, det her var blot nogle få.

Hvad med dig? Har du et JavaScript-trick du vil dele i kommentarerne?

Ellers vil jeg anbefale at du hopper over på codewars.com, så lærer du helt sikkert noget nyt.

Kommentarer (41)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Zedeler

...at lyde som en sur, gammel Perl-udvikler, så findes der netop i Perl mere elegante versioner af samtlige af ovenstående (måske lige pånær max-udtrykket som kræver et separat modul). Nu vil jeg ikke gå dem alle sammen igennem, men her er nogle stykker:

a = Array.apply(null, new Array(10)).map(function (value, index){  
   return index;  
});

Bliver til

my @a = 0 .. 10;

og

if (['test1', 'test2', 'test3'].indexOf(v) !== -1){  
    //v er lig med test1, test2 eller test3  
}

bliver til

if(grep {$_ eq $v} qw{ test1 test2 test3}) {  
    ...  
}

Hvad kan man lære af det? At de fleste smarte teknologier og sprog er allerede opfundet. Vi genopdager dem bare igen en gang ca. hvert 10. år. (Dermed er det også underforstået at Perl ikke kom først med noget her...)

Desuden er JavaScript (nok mere ved et tilfælde end noget andet) endt med at være et sprog som lægger meget op til at bruge funktionsorienteret programmering. Desværre er syntaksen til netop den slags temmeligt tung når man sammenligner med andre sprog.

Her vil jeg så slå lidt på tromme for CoffeeScript, der eliminerer mange af de mest knudrede JavaScript-idiomer.

  • 2
  • 0
Allan Ebdrup Blogger

Hvad kan man lære af det? At de fleste smarte teknologier og sprog er allerede opfundet. Vi genopdager dem bare igen en gang ca. hvert 10. år.
<snip>
Her vil jeg så slå lidt på tromme for CoffeeScript, der eliminerer mange af de mest knudrede JavaScript-idiomer.

Hej igen Michael :-)
Med fare for at lyde provekerende, vil jeg sige at du helt har misset pointen. JavaScript er jo dynamisk, så hvis du virkelig har brug for en konstruktioner som range 0..10 (skulle det ikke være 0..9? Ellers er det en lidt forvirrende syntaks), så er den nemt at gøre dem genbrugelige.

Men ovenstående snippets er bare nogle eksempler på meget simple anvendelser af nogle mere generelle konstruktioner.

Range 0-9 eksemplet kan bruges til meget, meget andet end range. Fx en chain af .filter, .map og .reduce (den slags bruge jeg oftere og oftere)

I indexOf eksemplet kan arrayet fx indeholde andet end konstanter.

Og der er en del snippets du skylder forklaringer på ;-)

Men prøv at gå ind på codewars.com og tag nogle kataer, så vil du se hvad jeg mener når du ser de andres løsninger.

Ang. CoffeScript, vil jeg sige, at hvis man tror, at det at man slipper for at taste et par karakterer her og der med CoffeScript retfærdiggører at indføre et compilestep, skal tænke sig om en ekstra gang.

  • Jeg er et levende eksempel på at tastehastigheden ikke er afgørende. Jeg har aldrig fået mig skrumlet sammen til at lære ti-finger systemet og taster forholdsvis langsomt. Men som udvikler leverer jeg varen til fulde. Tastehastighed er ikke de der gør en god udvikler.
  • Jeg selv og folk i min omgangskreds vil helst ikke røre CoffeScript node-moduler. De bliver kun valgt hvis der abolut ikke er nogen vej udenom. Du skal regne med færre pull requests til dine open source CoffeScript projekter.
  • Hele debugging, stacktrace og turnaround på compile problematikken, for hvad? Der skal godtnok være en stor gevinst for at retfærdiggøre det. Jeg ser ikke at CoffeeScript udviklere klarer sig bedre end andre.

Men havde du ikke nogle ekselmper på smarte JavaScript-tricks, som indlæget handler om?

MVH

  • 0
  • 0
Bo Victor Thomsen
if (['test1', 'test2', 'test3'].indexOf(v) !== -1)

kontra

if (['test1', 'test2', 'test3'].indexOf(v) + 1)

får mig til at mindes min programmerings "ungdom" hvor man synes det var skide smart at få Pascal eller Fortran til at ligne Lisp - jeg blev hurtigt klogere...

For nu at citere et velkendt ordsprog, som alle programmører burde kende:

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

  • 9
  • 0
Carsten Gehling

Her vil jeg så slå lidt på tromme for CoffeeScript, der eliminerer mange af de mest knudrede JavaScript-idiomer.

Problemet med CoffeeScript (og Dart og andre, der prøver at genopfinde Javascript med en anden syntax) er, at hvis du koder til et browser UI, så sidder du og koder i én syntax, men kommer til at sidde og debugge og trace i en anden syntax. Det er ikke skide fedt.

Jeg var selv umiddelbart begejstret for CoffeeScript, især fordi jeg på serverside koder Ruby. Men jeg må indrømme, at forholdet et kølnet sidenhen.

Hvis du endelig vil forbedre JS - og det har jeg al mulig fuld forståelse for :-) - så vil jeg anbefale TypeScript. Det er 100% javascript men med stærke typer, klasser, moduler osv.

/ Carsten

  • 3
  • 0
David Konrad

Man er ret dårligt stillet hvis ovenstående er ny læsning. Flere af eksemplerne ville endvidere blive downvotet på stackoverflow da de er regulært browser-afhængige. Jeg gad godt se

if (['test1', 'test2', 'test3'].indexOf(v) + 1){
//v er lig med test1, test2 eller test3
}

blive kørt på en IE7. Men det er sikkert bare mig, som er pernittengryn. Polyfill er kodeordet.

  • 0
  • 1
Ivo Santos

Et af ulemperne ved Javascript er at de avancerede ting ikke giver mening udfra hvad man er vandt til fra andre sprog så som for eksempel C/C++, Visual Basic, og så videre.

Tag for eksempel denne her:

if (['test1', 'test2', 'test3'].indexOf(v) !== -1)  
        printf("\n\nwhat??? ...\n\n");

Den C kompiler jeg anvender fortæller mig at der er 4 fejl i ovenstående kode, så hvad der virker i det ene sprog virker ikke i et andet sprog.

Som jeg tidligere har fortalt, jeg mener skrevet, så er jeg ganske vist hobby programmør, og selv om jeg burde kaste mig ud i .net, javascript, samt lignende sprog er jeg faktisk gået fra Visual Basic 6 til nu C programmering, hvilket giver en del udfordringer, fordi i C programmering skal man næsten lave alt selv, eller tæt på i hvert fald. Jeg har ganske vist forsøgt mig med javascript, men de avancerede ting har altid afholdt mig fra javascript, men det er da alligevel sjovt at se nogen danse med javascript.

  • 0
  • 8
Michael Zedeler

Problemet med CoffeeScript (og Dart og andre, der prøver at genopfinde Javascript med en anden syntax) er, at hvis du koder til et browser UI, så sidder du og koder i én syntax, men kommer til at sidde og debugge og trace i en anden syntax. Det er ikke skide fedt.

Det har jeg ikke oplevet som et problem i CoffeeScript - syntaksen er så tæt på, at jeg kan læse begge to. Desuden understøtter CoffeeScript source maps, så hvis man virkelig vil, kan man debugge i det også.

Hvis du endelig vil forbedre JS - og det har jeg al mulig fuld forståelse for :-) - så vil jeg anbefale TypeScript. Det er 100% javascript men med stærke typer, klasser, moduler osv.

Jeg har aldrig været specielt begejstret for alt for eksplicitte klassestrukturer. Hvis man bliver grebet af stemningen, ender de så mange mærkelige abstraktioner, at man taber målet af syne. Java er vist det bedste eksempel - jeg må indrømme at jeg kun meget sjældent savner alle de fine factory-klasser.

  • 0
  • 0
Michael Zedeler

Med fare for at lyde provekerende, vil jeg sige at du helt har misset pointen. JavaScript er jo dynamisk, så hvis du virkelig har brug for en konstruktioner som range 0..10 (skulle det ikke være 0..9? Ellers er det en lidt forvirrende syntaks), så er den nemt at gøre dem genbrugelige.

Range 0-9 eksemplet kan bruges til meget, meget andet end range. Fx en chain af .filter, .map og .reduce (den slags bruge jeg oftere og oftere)

Ja. Men jeg vil nok påstå at Perls syntaks er væsentligt mere læsbar. Turing-maskiner er også rigtig gode til at lave range-operatorer, men læsbarheden halter det lidt med. At man kan konstruere sig frem til alle den slags ting følger af at det er et turing-komplet sprog :-)

Det virkelig interessante spørgsmål er hvor anvendeligt, det er. Jeg synes at syntaksen er meget klodset, men ja - det virker da.

(Og ja - jeg har lavet en slåfejl - range-operatoren inkluderer begge endepunkter.)

Hvis du med "dynamisk" mener at man kan lave chaining af funktioner som filter, map og reduce, så er Perl også dynamisk (modulo reduce, som skal loades før man får adgang til den). Det har bare en langt mere kompleks syntax (på godt og ondt). Den komplekse syntaks er svær at læse for nybegyndere, men væsentligt mere kompakt.

Men ovenstående snippets er bare nogle eksempler på meget simple anvendelser af nogle mere generelle konstruktioner.

I indexOf eksemplet kan arrayet fx indeholde andet end konstanter.

Jeg ville blive meget overrasket hvis det modsatte var tilfældet :)

Og der er en del snippets du skylder forklaringer på ;-)

Ja - jeg tog kun en håndfuld frem for ikke at mit indlæg skulle blive for langt og tørt. Hvis der er en bestemt snippet, du gerne vil have oversat, gør jeg det gerne. De har allesammen nogle relativt pæne Perl-paralleller.

Men prøv at gå ind på codewars.com og tag nogle kataer, så vil du se hvad jeg mener når du ser de andres løsninger.

Ja. Jeg er lige blevet registreret. Det ser meget fint ud. Rigtig god idé.

Ang. CoffeScript, vil jeg sige, at hvis man tror, at det at man slipper for at taste et par karakterer her og der med CoffeScript retfærdiggører at indføre et compilestep, skal tænke sig om en ekstra gang.

Jeg er et levende eksempel på at tastehastigheden ikke er afgørende. Jeg har aldrig fået mig skrumlet sammen til at lære ti-finger systemet og taster forholdsvis langsomt. Men som udvikler leverer jeg varen til fulde. Tastehastighed er ikke de der gør en god udvikler.    
Jeg selv og folk i min omgangskreds vil helst ikke røre CoffeScript node-moduler. De bliver kun valgt hvis der abolut ikke er nogen vej udenom. Du skal regne med færre pull requests til dine open source CoffeScript projekter.    
Hele debugging, stacktrace og turnaround på compile problematikken, for hvad? Der skal godtnok være en stor gevinst for at retfærdiggøre det. Jeg ser ikke at CoffeeScript udviklere klarer sig bedre end andre.  

Det har nok også betydning hvad det præcis er, man arbejder med, men for mig har læsbarhed altid relativt høj prioritet. Jeg synes ikke at JavaScripts mange, mange closures og for så vidt også de lange kæder, du bringer eksempler på her, er særligt nemme at læse.

På den ene side er jeg enig med dig i at længden af koden ikke har indflydelse i forhold til den hastighed, man koder med, men på den anden side er jeg fanatisk tilhænger af kort kode, da jeg er overbevist om at reglen om at antallet af fejl er proportional med kodens længde holder.

Og ja - jeg tror også at der opstår flere fejl når folk skal skrive "function bob() { ... }" frem for "bob = ->" eller "name = futurists.poet.name; street = futurists.poet.address[0]; city = futurists.poet.city[1];" frem for "{poet: {name, address: [street, city]}} = futurists", men selvfølgelig er der tale om en afvejning.

Det er rigtigt at der er lidt længere turnaround på CoffeeScript, men pt. bruger jeg det på et system hvor man alligevel skal uploade koden til en server, for at se hvordan det virker. At få det oversat først er ret hurtigt. Det afgørende er at jeg kan oversætte og uploade med een kommando.

Men havde du ikke nogle ekselmper på smarte JavaScript-tricks, som indlæget handler om?

Beklager - jeg kom vist til at oversætte dem til Perl :-)

  • 1
  • 0
Allan Ebdrup Blogger

Hvis du med "dynamisk" mener at man kan lave chaining af funktioner som filter, map og reduce,

Nej jeg mente bare at du kunne jo lave en var a = Array.range(0,9), hvis du ville. Det kan der så være gode grunde til ikke at gøre, men det er muligt.

Ang. CoffeScript, så synes jeg det er lidt off-topic. Men det eneste jeg sagde var at man skulle tænke sig godt om - jeg kan ikke komme på en situation hvor jeg ville vælge det. Dermed også sagt at jeg ikke køber dine argumeter for CoffeScript.

Men codewars, som indlæget handler om, har også CoffeScript kataer, der kan du sikkert lære lige så mange CoffeScript tricks som man kan lære JavaScript-tricks i JavaScript delen. :-)

  • 0
  • 0
Allan Ebdrup Blogger

Man er ret dårligt stillet hvis ovenstående er ny læsning.


Indlæget tager udgangspunkt i codewars.com, jeg tror der er en del der ikke kender det.

Ang. eksemplerne, så er det lidt svært at komme med de mere avancered eksempler i en blogpost. Derfor opfordringen til at besøge codewars selv.

Hvis du går ind på codewars vil du se hvorfor jeg nævner eksemplerne, du får brugt dem på nye måder, når du løser kataer.

Min favorit, indtil videre, er snail kataen:
http://www.codewars.com/dojo/katas/521c2db8ddc89b9b7a0000c1/play/javascript
Udfordringen er, at få din løsning til den til at være den mest up-votede løsning på codewars.

Flere af eksemplerne ville endvidere blive downvotet på stackoverflow da de er regulært browser-afhængige. Jeg gad godt se

if (['test1', 'test2', 'test3'].indexOf(v) + 1){
//v er lig med test1, test2 eller test3
}

blive kørt på en IE7. Men det er sikkert bare mig, som er pernittengryn. Polyfill er kodeordet.

Det var også derfor der var et link til en shim i indlæget (Så det virker i IE7).

Jeg vil mene at ordet faktisk er shim, ikke polyfill, da det bare sørger for at gamle browsere kan gøre det samme som nye browsere, og det der implementeres er en del af EcmaScript spec'en.

  • 0
  • 0
Palle Simonsen

Jeg vil mene at ordet faktisk er shim, ikke polyfill, da det bare sørger for at gamle browsere kan gøre det samme som nye browsere, og det der implementeres er en del af EcmaScript spec'en.

Korrekt - polyfill er et begreber i computer grafik, Det er godt at fagets ord bruges, men endnu bedre, hvis de bruges korrekt.

Som (sur) gammel LISP programmør synes jeg at Javascript er et rigtig fedt sprog - særlig er jeg vild med 'prototypical classes'. Jeg kan simpelthen ikke forstå, hvorfor folk er så vilde med at nedgraderer sproget til at være på niveau med f.eks. Java. Er det fordi det kniber med abstraktionsevnerne derude? :)

  • 1
  • 0
Allan Ebdrup Blogger

Problemet med det kriterie er at bunken af løsninger til de fleste af opgaverne er alt for stor, vigtigere end alt andet er at komme først med en løsning så den ikke drukner i mængden.


Det er ikke så svært. Hvis du løser den, og mener at din egen løsning er den bedste, kan du give dig selv en up-vote. Så er du allerede i top 10. Hvis det vitterlig er den bedste løsning, skal den nok komme i toppen :-)

  • 0
  • 1
Thomas Søndergaard

Jeg er et levende eksempel på at tastehastigheden ikke er afgørende. Jeg har aldrig fået mig skrumlet sammen til at lære ti-finger systemet og taster forholdsvis langsomt. Men som udvikler leverer jeg varen til fulde. Tastehastighed er ikke de der gør en god udvikler.

Ovenstående fik mig til at tænke på følgende fra Kent Beck:

I've known people who have not mastered their tools who are good programmers, but not a tool master who remained a mediocre programmer

Så det er da muligt at du er en udmærket udvikler, men det er et dårligt tegn at du ikke har valgt at bruge tid på at mestre et temmelig relevant værktøj - dit keyboard :-)

  • 0
  • 5
Bo Victor Thomsen

Tænk, jeg kender adskillige programmører som grundet deres mestren af ti-finger systemet kan sprøjte kode ud i kilometervis. Det bliver koden såmænd ikke bedre af. Sagt på en anden måde - det er ikke dine fingres hastighed, som afgør din kunnen mht. programmering. Ellers ville Eric "Slowhand" Clapton velsagtens også blive karakteriseret som en dårlig guitarist....

  • 3
  • 0
Bo Victor Thomsen

Hvorfor siger du det? Hvis I anvender 3. parts biblioteker er der sikkert en del af den slags tricks i dem.

Det gør squ da ikke sagen bedre mht. til din egen kode !!

For nu at brodere lidt på eksemplet fra bloggen:

1.if ('test1'.indexOf(v) !== -1 || 'test2'.indexOf(v) !== -1 || 'test3'.indexOf(v) !== -1)
2.if (['test1', 'test2', 'test3'].indexOf(v) !== -1)
3.if (['test1', 'test2', 'test3'].indexOf(v) + 1)

Udgave 1 er ordinær, men man er ikke i tvivl om hvad koden gør.

Udgave 2 er en intelligent løsning, fordi den er elegant og læsevenlig på samme tid. Man skal have forklaret konstruktionen een gang - så ved man hvad den gør.

Udgave 3 er "smart" og total håbløs: Når man læser den 1. gang tænker man "WTF"!! Og derefter skal man analysere, at udtrykket bliver sandt når det 1. led i addenden er forskellig fra -1 - fordi så bliver det den samlede addend ikke 0 som er "falsy" i javascript.

Og hvorfor gør man det ? Det må guderne vide - men man kan gætte på at "programmøren" vil spare at skrive 3 karakterer !

  • 5
  • 0
Allan Ebdrup Blogger

Udgave 3 er "smart" og total håbløs: Når man læser den 1. gang tænker man "WTF"!! Og derefter skal man analysere, at udtrykket bliver sandt når det 1. led i addenden er forskellig fra -1 - fordi så bliver det den samlede addend ikke 0 som er "falsy" i javascript.

Det er jeg enig i. Det er også derfor der i blogindlæget står:

Det vil jeg dog umiddelbart ikke gøre i kode jeg skal vedligeholde

Underforstået at, det skal man ikke gøre i kode der rent faktisk skal bruges til noget som helt andet end leg som codewars.

Angåend dine eksempelr, så ville nummer et som du skriver:

1.if ('test1'.indexOf(v) !== -1 || 'test2'.indexOf(v) !== -1 || 'test3'.indexOf(v) !== -1)

I 'standard'-udgaven nok nærmere være:

if ('test1' === v || 'test2' === v || 'test3' === v)
  • 1
  • 0
Allan Ebdrup Blogger

Det er ikke så svært. Hvis du løser den, og mener at din egen løsning er den bedste, kan du give dig selv en up-vote. Så er du allerede i top 10. Hvis det vitterlig er den bedste løsning, skal den nok komme i toppen :-)


Down-vote til denne kommentar kunne tyde på, at jeg lige bør præcisere, at det er helt indenfor reglerne at up-vote sin egen løsning på codewars, hvis man synes den er den bedste.

  • 0
  • 0
Rune Jeppesen

Mange tak for tippet - den side vil jeg helt sikkert få brugt. Jeg har kun lige fået lavet den første. Jeg kan godt lide at man også skal skrive sine tests allerede i anden runde - så kan man lære det!

Ligesom Carsten G. vil jeg også varmt anbefale Typescript - så lækkert at blive gjort opmærksom på at det ikke giver mening når man f.eks. i en loop skriver '..;i<linjer;... og bliver gjort opmærksom på at det ikke giver mening (der bør stå linjer.length)

Her er en 'kod-javascript-under-stress' leg: Dave Ward kunne på 3 min og 19 sek - jeg kunne slet ikke :(
http://toys.usvsth3m.com/javascript-under-pressure/

  • 0
  • 0
Jacob Christian Munch-Andersen
  • 1
  • 0
Bo Victor Thomsen

Ups, I har ret. Det viser 2 ting:

  1. Jeg er en klaphat til JavaScript (Har ikke beskæftiget mig med sproget i tre år)

  2. Min pointe med at programkode bør være læsevenlig, så også uerfarne / gennemsnitlige / morderiske javascript programmører (der ved hvor du bor) forstår koden. Du ved jo aldrig, hvem der kommer bagefter og skal vedligeholde din super duper kode.

Med fare for at også blive en pompøs klaphat vil jeg slutte af med et citat af Einstein:

Make everything as simple as possible, but not simpler

  • 2
  • 0
Bjarke Walling

Her er nogle tricks, som jeg ofte bruger:

// Vær sikker på at a er en integer (eller 0, hvis den ikke kan fortolkes).  
a = a | 0;  
   
// Konverter b til en streng, men sørg for at null/undefined bliver en tom streng.  
b = ('' + [b]);  
   
// sæt en default-værdi for value, hvis den er "falsy".  
value = value || 'foo';

Det er meget praktisk, når man kender dem (og derved kan læse koden).

  • 3
  • 0
Niels Henriksen

Denne som Bjarke kommer med

// Konverter b til en streng, men sørg for at null/undefined bliver en tom streng.
b = ('' + [b]);

Benytter jeg altid i de forskellige sprog jeg sidder med. Den kan udvides til

b = Int32.Parse("0" + variabel); (nu er det så C#) for at sikre mig at b nu også ER et tal.

  • 0
  • 0
David Konrad

Jeg blev vanen tro downvotet, og lad fjolserne om det - men er du uenig i, at indexOf ikke kan bruges i alle browsere, og du dermed må bruge polyfill før dine "smarte" tricks du har fundet på en hjemmeside (=jævne programmeringsforslag) kan anvendes i praksis? De ville ikke virke i IE7 eller IE8 t.ex .. Blev først implementeret fra 1.6, hvilket du kan se her https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global... - i øvrigt sammen med et polyfill eksempel

  • 0
  • 2
Allan Ebdrup Blogger

Jeg blev vanen tro downvotet, og lad fjolserne om det


David, vi er her for at dele erfaringer og blive kloger i fælleskab. Men det kræver at man har lyst til at bidrage konstruktivt. Jeg vil gerne høre hvad du har at bidrage med, men det er lidt svært at få noget konstruktivt ud af det, når du ikke læser de svar jeg allered har givet.

Jeg vil meget gerne lære noget af det du ved om JavaScript, for ingen ved alt og ingen er perfekte. Men det kræver også en ordenlig tone, hvis det skal være sjovt.

  • 1
  • 0
Sune Marcher

Korrekt - polyfill er et begreber i computer grafik, Det er godt at fagets ord bruges, men endnu bedre, hvis de bruges korrekt.


"Polyfill" kommer af polyfilla, og er IMHO et bedre term end "shim", da jeg mere betragter en shim som noget der intercepter data, "masserer et API i form", eller lignende - web polyfills, derimod, er kun beregnede på at fylde mangler standard-APIet ud.

  • 0
  • 0
Log ind eller Opret konto for at kommentere