Robert Baillie

One of the really elegant parts of Lightning Components was the ability to conditionally apply classes based on data. This is something that is no longer available to us, as the expressions we are allowed to put into templates are now limited to either: A property of the Javascript class (or a sub-property that can be referenced through a top level property). A getter, that accepts no parameters. I’ve already mentioned a change in this area in this blog post about building re-usable components, but I felt it was time to drill into this just a little further... The scenario Let’s say we want to render a list of objects. There’s a flag 'isSelected' on each of the records, and if that flag is set we want to change the rendering for that particular record. JSON data: [ { "id" : 1 , "name" : "Anne" , "isSelected" : false }, { "id" : 2 , "name" : "Bob" , "isSelected" : true }, { "id" : 3 , "name" : "Carla" , "isSelected" : true } ] Required Output: <ul> <li...

Another fantastic inclusion in Lightning Web Components is the completely reworked events model. De-composing functionality and building smaller, and more generic building blocks has become much simpler and much more intuitive. In the world of Lightning Components I never got on with events. The idea of adding a Salesforce configuration for an event, registering events on the dispatcher template, and then registering listeners on the receiving template seemed really cumbersome. And then added onto that was the differences in syntax between component and application events. They just felt really unnatural. In Lightning Web Components all this has become significantly simpler, and much more in-keeping with the standard HTML / Javascript model. We've already seen how we can use @api allow state to be passed into our components. Now we're talking about notifying our parents when events occur. I could go into deep detail on how this is done, but the documentation on this area is...

One of the things I’m most excited about in Lightning Web Components is the ability to write Unit Tests for the components. The unit testing framework of choice is Jest, and it looks well suited. Not least it’s the framework of choice for Facebook, and describes itself as well suited to React apps. Why should that matter? Well, React is a 1-way bound Javascript framework - and so is LWC. So I was looking forward to get into Unit Testing, following the documentation for testing wired components Unfortunately, the documentation didn’t work out for me, and it looked like there’s a couple of mistakes in there: The example ‘getRecord.json’ file isn’t valid JSON. In order for the file to work, the field names need to be surrounded in double quotes. I.E. Instead of: // getRecord.json { fields: { Name: { value: "DYNAMO X1" } } } The file should be: // getRecord.json { "fields": { "Name": { ...

I've blogged about a few of the behaviours of Lightning Web Components, but the proof is really in building useful bits. What happens when you actually try to make a re-usable component? For our example, we'll rebuild 'ui:message'. A now (seemingly) defunct base component that would render a message in a box that is coloured based on the 'severity' of the message being shown. In the original it could be set to 'closable', although we're going to ignore that and focus on just the rendering of it. In a Lightning component we would use it like this:Original usage - Lightning Component <ui:message title="Error" severity="error" >{!v.errorMessages}</ui:message> Ideally, the version we will create, would be used like this:Desired usage <c-message title="Error" severity="error" >{errorMessages}</c-message> Looks pretty straightforward, and actually - it is. Just as long as we know about a few simple concepts. Before we go into them, let's see what a working...

Following on from yesterday's investigations into the behaviour of '@track', and its effect on untracked properties, I figured I should expand my remit to '@wire'. My main reason for that was the statement in the documentation: In the wire adapter’s configuration object, prefix a property with $ to reference a property of the component instance. The $ prefix tells the wire service to treat it as a property of the class and evaluate it as this.propertyName. The property is reactive. If the property’s value changes, new data is provisioned and the component rerenders. This comment relates to code along the lines of: @api recordId; @wire(getRecord, { recordId: '$recordId', fields }) contact; The bit that really piqued my interest was 'The property is reactive'. In all the examples, it looked like the property being referenced was always tracked or set as an api field (the latter implying the former) That's the case in the above example - the property passed as a...

On Friday I wrote an excited blog post on the introduction of Lightning Web Components. One of the things I mentioned was that I didn't quite get how '@track' was supposed to work Since then, I've found the documentation (add /docs/component-library/documentation/lwc/lwc.get_started_introduction to the end of your Salesforce URL), read it, got confused by my memory, wrote a test-rig and looked at it all in depth. On the surface, it's simple, but there are some complications, which were the cause of my confusion... In the documentation it says the following: Both @track and @api mark a property as reactive. If the property’s value changes, the component re-renders. OK, nice and simple. So what does that mean? A single untracked property Testing with a simple component that contains a single property that is not tracked I found the following behaviour: Javascript component export default class TrackExperiments extends LightningElement { primitiveUntracked; ...

Salesforce have a new technology. Lightning Components look like they’re on the way out, and are being replaced with a new technology ‘Lightning Web Components’. The reasons behind that, and the main principles behind its design are covered very nicely in this article on developer.salesforce.com. From that we can then get to a series of examples here. (Note: some of the code snippets used below, to illustrate points, are taken from the recipes linked above) Now I’m a big supporter of evolution, and I love to see new tools being given to developers on the Salesforce platform, so, with a couple of hours to play with it - what’s the immediate impression? This is an article on early impressions, based on reviewing and playing with the examples - I fully expect there to be misunderstandings, bad terminology, and mistakes in here - If you're OK with that, I'm OK with that. I admit, I got excited and wanted to post something as quickly as possible before my cynical side took over. So...

I should start this post by saying I’m neither a lawyer, nor a GDPR expert.  Possibly both of those facts will become massively apparent in the text that follows. Also, I’m not a LinkedIn Premium user - so it’s possible I’m missing something obvious by not having access to it. But anyway, I’ve been thinking about how LinkedIn fits into a GDPR world, and it doesn’t something doesn’t seem quite right to me at the moment. LinkedIn are in the data business, and they’re very good at protecting that asset.  They tend to be (quite rightly) pro-active in stopping people from extracting data from their systems and pushing it into their own systems. As such, businesses (recruiters particularly) are encouraged to contact directly within LinkedIn, and they are offered tools to discover people and commence that communication. Unfortunately, this lack of syncing between LinkedIn and in-house systems can cause a big problem with GDPR. That is: What happens if someone says to a recruitment...

Over 10 years ago I wrote a blog post on things that I believe in - as a developer, and when I re-read it recently I was amazed at how little has changed. I'm not sure if that's a good thing, or a bad thing - but it's certainly a thing. Anyway - here's that list - slightly updated for 2018... it you've seen my talk on Unit Testing recently, you might recognise a few entries. (opinions are my own, yada yada yada) It's easier to re-build a system from its tests than to re-build the tests from their system. You can measure code complexity, adherence to standards and test coverage; you can't measure quality of design. Formal and flexible are not mutually exclusive. The tests should pass, first time, every time (unless you're changing them or the code). Test code is production code and it deserves the same level of care. Prototypes should always be thrown away. Documentation is good, self documenting code is better, code that doesn't need documentation is best. If you're getting bogged...

In 2015, the ECMA specification included the introduction of Promises, and finally (pun intended) the Javascript world had a way of escaping from callback hell and moving towards a much richer syntax for asynchronous processes. So, what are promises? In short, it’s a syntax that allows you to specify callbacks that should execute when a function either ’succeeds’ or ‘fails’ (is resolved, or rejected, in Promise terminology). For many, they're a way of implementing callbacks in a way that makes a little more sense syntactically, but for others it's a new way of looking at how asynchronous code can be structured that reduces the dependancies between them and provides you with some pretty clever mechanisms. However, this article isn’t about what promises are, but rather:  ‘How can Promises be used in Lightning Components, and why you would want to’. If you want some in depth info on what they are, the best introduction I’ve found is this article on developers.google.com In...

"Proof of Concepts" are a vital part of many projects, particularly towards the beginning of the project lifecycle, or even in the pre-business case stages.They are crucial for ensuring that facts are gathered before some particularly risk decisions are made.  Technical or functional, they can address many different concerns and each one can be different, but they all have one thing in common.  They serve to answer questions.It can be tempting, whilst answering these questions to become attached to the code that you generate.I would strongly argue that you should almost never keep the code that you build during a POC.  Certainly not to put into a production system.I'd go so far as to say that planning to keep the code it is often damaging to the proof of concept; planning to throw the code away is liberating, more efficient and makes proof of concepts more effective by focussing the minds on the questions that require answers..Why do we set out on a proof of concept?The...

Let me paint a simple picture (but with lots of numbers). Some software has been built.  It generates revenue (or reduces cost) associated with sales, but the effect is not immediate.  It could be the implementation of a process change that takes a little time to bed in, or the release of a new optional extra that not everyone will want immediately. It is expected that when it is initially released there’ll be a small effect.  Over the next 6 months there will be an accelerating uptake until it reaches saturation point and levels off. Nothing particularly unusual about that plan.  It probably describes a lot of small scale software projects. Now let’s put some numbers against that. At saturation point it’s expected to generate / save an amount equal to 2% of the total revenue of the business.  It might be an ambitious number, but it’s not unrealistic. The business initially generates £250k a month, and experiences steady growth of around 10% a year. What...

I keep on forgetting how to type é on Windows 8 (I used to CTRL+ALT+e, but that's now often reserved for the Euro symbol) I then tend to run a search on Google, and end up being pointed towards 8 year old answers that point you to character map, options in old version of word, or the old way of typing the extended ASCII character code. They all suck. And then I remember - it's easy. You start by pressing a CTRL + a key that represent the accent, then type the letter you want accented. For example, CTRL + ' followed by e gives you é. Brilliant! The great thing about using this technique is that the characters you use (dead letters) are representative of the accents you want to type. This makes them much easier to remember than the seemingly random character codes Here are the ones I know about: KeystrokesAccent typeExamplesCTRL + 'acuteéCTRL + `graveèCTRL + SHIFT + 6 / CTRL + ^circumflexêCTRL + ,cedillaçCTRL + ~perispomeneõCTRL + SHIFT + 7 / CTRL + &Diphthongs / others a =...

Since the end of July last year I've been test driving one of the latest online tools that hopes to change your life by giving you the ability to store your task lists. Wow. What could be more underwhelming, and less worthy of a blog post? Well, this one is different.  This one takes some of the huge amount of thinking on the behaviour of "millenials" and "Generation Y", adds a big dose of social context and ends up with something quite spectacular. This is the gamification of task lists, this is experience points and levelling up, buying armour and using potions, this is World of Warcraft where the grinding is calling your mam, avoiding junk food or writing a blog post. This is HabitRPG.The concept is simple, you manage different styles of task lists.If you complete entries on them you get experience points and coins.If you fail to do entries them you lose hit points. Depending on on whether you're setting yourself realistic targets and completing them you either level up, or...

Do you have a problem with the BBC website? Even though you're based in the UK it seems to have a lot of adverts for American companies on it? And it's not that you don't like American companies, it's just that you've already paid your licence fee and that means that you shouldn't have to see any adverts at all.Even worse than that, because it thinks you're not in the UK, it won't let you access any of the iPlayer content! At some point in the last few weeks that started to happen to me on my Android (Nexus 10, no less) tablet. Thankfully I managed to solve it. A quick scan of the BBC help seemed to just direct me to my ISP (they may route you through foreign / non-UK servers - I knew this wouldn't be true as my desktop works OK, and it doesn't sound like BT). A quick mail to them seemed to confirm my fears - no problem there. A mail to the BBC was never going to be much use. I don't blame them, they have a lot of people to deal with and none of them pay a subscription fee that's...

As far as I can see, there is only one reason why a company should ever make redundancies.Due to some unforseen circumstances the business has become larger than the market conditions can support and it needs to shrink in order to bring it back in line.Every other reason is simply a minor variation or a consequence of that underlying reason.Therefore, if the motivation is clear, and the matter dealt with successfully, then once the redundancies are over the business should be "right sized" (we've all heard that term before), and it should be able to carry on operating with the same values, practices and approach that it did prior to the redundancies.If the business can't, then I would suggest is that it is not the right size for the market conditions and therefore the job isn't complete.OK, there may be some caveats to that, but to my mind this reasoning is sound.In detail:When you reduce the headcount of the business you look for the essential positions in the company, keep those,...

User experience design is an agile developer's worst nightmare. You want to make a change to a system, so you research. You collect usage stats, you analyse hotspots, you review, you examine user journeys, you review, you look at drop off rates, you review. Once you've got enough data you start to design. You paper prototype, run through with users, create wireframes, run through with users, build prototypes, run through with users, do spoken journey and video analysis, iterate, iterate, iterate, until finally you have a design. Then you get the developers to build it, exactly as you designed it. Agile development, on the other hand, is a user experience expert's worst nightmare. You want to make a change to a system, so you decide what's the most important bit, and you design and build that - don't worry how it fits into the bigger picture, show it to the users, move on to the next bit, iterate, iterate, iterate, until finally you have a system. Then you get the user experience...

Burn-down (and burn-up, for that matter) charts are great for those that are inclined to read them, but some people don't want to have to interpret a pretty graph, they just want a simple answer to the question "How much will it cost?" That is if, like me, you work in what might be termed a semi-agile*1 arena then you also need some hard and fast numbers. What I am going to talk about is a method for working out the development time left on a project that I find to be pretty accurate. I'm sure that there are areas that can be finessed, but this is a simple calculation that we perform every few days that gives us a good idea of where we are. The basis.It starts with certain assumptions: You are using stories.OK, so they don't actually have to be called stories, but you need to have split the planned functionality into small chunks of manageable and reasonably like sized work. Having done that you need to have a practice of working on each chunk until its finished before moving on to...

Gotta admit, I'm quite pleased with this line from my new ORM object based database connection library... $oFilter = Filter::attribute('player_id')->isEqualTo('1')->andAttribute('fixture_id')->isEqualTo('2');

As part of any iteration review / planning meeting there should be a section where everybody involved talks about how they felt the last iteration went, what they thought stood in the way, what they though went particularly well and suchlike. We find that as the project goes on, and the team gets more and more used to each other, this tends to pretty much always dissolve into everyone going "alright I suppose", "yeah fine". Obviously, this isn't ideal and will tend to mean that you only uncover problems in the project when they've got pretty serious and nerves are pretty frayed. This is where "The Happiness Meter" comes in. Instead of asking the team if they think things are going OK and having most people respond non-committally, ask people to put a value against how happy they are with the last iteration's progress. Any range of values is fine, just as long as it has enough levels in it to track subtle movements. I'd go with 1-10. You don't need strict definitions for each...