Implementing all day

This is my personal coding blog

Hent ikke jQuery 2 gange

“There can be only one..”

Jeg har vænnet mig til at bruge requireJS, som min afhængigheds- , og buildframework, når jeg fremstiller MarionetteJS applikationer. Jeg har vænnet mig til at definerer moduler, så de både kan indlæses med requireJS, og opfylde MarionetteJS modul-definitioner. Det virker perfekt, og jeg har egentlig ikke tænkt videre over,hvilke komplikationer dette setup, kan medfører i blandede scenarier. For nyligt skulle jeg implementerer en lille applikation, på en side i en større portal. Jeg fremstillede min main.js fil, og loadede applikationen og afhængigheder som jeg plejer. Jeg placerede script-elementet som det sidste i Html’en. Alt virkede som det skulle. Lige ind til en eksterne konsulent besluttede at forskønne Html’en med en jQuery-udviddelsesmodul (selectBoxIt http://www.selectboxit.com). Nu fik jeg pludselig problemer med at select-elementer, ikke kunne sættes til værdier via script, og ligeledes virkede det som om at disse, heller ikke længere rejste hændelser i DOM’en. I følge udvidelsesmodul-dokumentatinen, skulle SelectBoxIt godt nok skjule det oprindelige Html-element, men alle metoder og hændelser, skulle forsætte med at virke. Det så bare ikke ud til at være tilfældet på denne portalside. Efter længere tids efterforskning, og utallige stoppunkts undersøgelser, fand jeg frem til problemet. Det viste sig at requireJS indlæste jQuery, som allerede fandtes i det globale objekt (window). Det giver i sig selv ingen problemer, ud over at det er en kende ineffektivt at hente jQuery 2 gange. Problemet var at SelectBoxIt udviddelsesmodulet, blev fjernet fra det jQuery modul, som endte i globalen. Derfor blev UI afkoblet fra select-elementets hændelser og metoder. Jeg brugte ikke selv SelectBoxIt, så jeg ville ikke introducerer denne afhængighed til applikationen, og requireJS shim funktion virkede jo ej heller. Så slog det mig, og løsningen var yderst simpel og ligetil. Jeg fjernede jQuery i mit path-element i require.config kaldet, og så indføjede jeg et kald til define, for at deffinerer jQuery for requireJS, og dermed for min applikation.

define('jquery', [], function(){
	return window.jQuery;
});

 

Andet skal der ikke til. På denne måde har jeg sikret at jQuery kun hentes een gang, og min applikation, behøver ikke at være afhængig af SelectBoxIt, eller havd nu designere og andre kreative sjæle, nu finder på at introducerer til siden. Eneste problem, er at min app nu vil fejle, hvis jQuery skulle forsvinde fra siden. Sansynligt? Nej vel…
Code on…

Så hvad er der i C# 6? Egenskabsinitialicering og primærkonstruktør

Jeg har set lidt på, hvad der venter os i den kommende opdatering af c# - version 6.

Ind til nu, har egenskabsinitialicering foregået nogenlunde således:

public class Person
{
	public Person(string navn)
	{
		this.Navn = navn;
		this._id = Guid.NewGuid();
	}

	public string Navn { get; set; } 
	
	private Guid id;
	public Guid ID { get{ return id; } }
}

Man er nød til at have et backing-felt, for at kunne tildele readonly egenskaben id med en værdi.

I C# 6 kan man nu initialicerer egenskaben direkte hvor egenskaben erklæres i koden.

public class Person
{
	public string Navn { get; set; } = "Jesper"; 
	public Guid ID { get; } = Guid.NewGuid();
}

Læg mærke til at vi med denne syntaks, ligeledes kan udelade setteren, og reelt gøre egenskaben uforanderlig. For at opnå dette tidligere, måtte man, som sagt, ty til at implementerer backing-felt. Det vil gøre klasse-koden kortere, mere kompakt og samle definition og initialisering i koden.

Denne syntaks leder os så hurtigt videre, til det lidt større koncept – primær konstruktøren. En primær konstruktør, gør det muligt for os at definerer en konstruktør for en klasse, og tilgå parametrene i resten af klassekroppen:

public class Person(string navn, int alder)
{    
	public string Navn { get; } = navn;    
	public int Alder { get; } = alder;
} 

Det nye består i at man angiver parametre i parentes efter klasse-navnet. Alle andre konstruktører skal så kalde ind til primærkonstruktøren, via this() syntaksen. Kompileren vil rejse fejl, hvis man forsøger sig uden kald til primærkonstruktøren. Det sker for at garanterer at primærkonstruktør-parametrene er til rådighed i hele klassekroppen.

public class Person(string navn, int alder)
{
    public Person(string navn) 
		: this(navn, 0){}    
	
	public string Navn { get; } = navn;    
	public int Alder { get; } = alder;
} 

Igen må man sige vi får en yderst kompakt og funktions orienteret kode, men hvad så med validering af input til primær konstruktøren. Det gøres nemt ved at tilføje en separat kodeblok i klasse kroppen:

public class Person(string navn, int alder)
{    
	{
         if(navn == null) throw new Exception("Navn skal angives");    
	}    
	
	public string Navn { get; } = navn; 
}

Man kan med sidstnævnte primærkonstruktør blok, nok argumenterer for hvor meget mere simpel syntaksen bliver.
Alt I alt et sæt features, der gør arbejdet med til at skrive kode kortere. Om man synes om syntaksen, og mener at det bliver mere overskueligt, er vel op til den enkelte udviklers temperament. Jeg selv elsker jo korte, eksplicitte sætninger, så mon ikke jeg tager den til mig ret hurtigt.

Code on…