If you are reading this, Force.com Lightning Components are something you’ve probably heard about by now. However, if your situation is at all like mine, you’re probably finding very few people doing much of anything with them yet, especially when it comes to doing so for commercial customers. Sure, you may know some folks who are messing with them in a dev org or perhaps have even written something for the App Exchange, but you’ve not really seen anyone working on Lightning Apps for their customers “in the wild.”

I think this is largely because there is quite a bit to learn, and they’re still relatively new, so for those forging ahead, you’re quite possibly in some uncharted waters. This is the boat that I happened to find myself in the past couple of weeks.

I was asked about the feasibility of doing a Lightning App for a client and while I was extremely excited, I was also extremely intimidated. I don’t yet know all the things that I don’t know, and I know that I don’t know quite a bit. (That was probably more fun for me to type that it was for you to read).

I had to do some research so I took some personal time and borrowed this client’s use case as my test bed. Don’t get me wrong, Trailhead is a great way to get started but there’s nothing quite like learning from a real-world example.

I had grandiose plans to have some workable code examples to blog about, but billable hours call and I’ve not put anything together yet that I believe one would find useful, but I did manage to learn a few lessons in the few short hours that I put in. Here are my top 5 takeaways so far:

#1) You have to create more components than you think. There’s been quite a bit of talk around reusable components, built in “stuff” etc. All of that is indeed coming I’m sure but as it stands right now there aren’t too many ready-to-fly components. For instance: I expected to find a prebuilt ui component that I could load in a list view that would be “tappable/clickable” etc. There may be one, but I couldn’t find it and after talking with a few people who are currently toying with these things, the general consensus was that I’d have to write my own. The goal of this component was to, at the very least, fire an event that I could listen to and then use that even to load a custom view component. (A force:recordView action exists, but that wasn’t going to work for this case, and even so the component that one would wire up to fire that event doesn’t seem to exist). Which brings me to the next item.

#2) Its all about Events. Components need to fire events to tell other components and bits of code you write to load/execute. I already knew this was the case but didn’t realize the extent to which you would employ events. I attempted to use an existing lightning event when my custom item list component was tapped. For some reason that event never loaded, so I decided it’d be a good time to attempt to write my own event as an experiment. That one indeed fired without issue. Then I realized that its all well and good that I fired the event (and handled it in the parent component), but then realized I’d need to fire yet another event to tell my components to swap in and out. Essentially a navigation event. (I’m still working on this but I haven’t finished…because consulting).

#3) “Physical” structure is very important to consider right out of the gate.Often times I trudge forward and just figure things out along the way, and that’s what I was doing here. However when it came time start figuring out how to swap components in an out, etc I realized that I actually need a top-level component that would own all other components. I had thought I originally created a top level component but then realized what I actually created was just the first component that the user will see. I wound up building another top level component that would house this original component as well as be responsible for swapping in/out other components as fired events dictate. I’m envisioning now that this top level component will essentially be responsible for handling APPLICATION level events (such as navigation events perhaps) and knowing which component is currently being viewed, etc. Had I thought of that fact up front, I would have saved myself some refactoring. (NOTE: this is all still theory as I haven’t completed my navigation components yet, maybe this won’t work…I dunno yet).

#4) Be as generic as possible. The overall goal — since we’re doing all this low-level component work — is to wind up with reusable components that you could possibly use in other apps. For instance, my ClickableListItem component and ItemSelectedEvent take an object Id, type and name. I can use that component and that event to display any object as well as tell whichever component that holds it that it was clicked and give that component access to the object ID through the event. I can use this in any app I write. I’m trying to remember this moving forward especially with regards to navigation. Ideally I’d love to be able to load components dynamically and have to solve that problem only once rather than re-invent the wheel for every app.

#5) It creates a ton of files. I currently have one screen and a few events but there are nearly 50 separate files. (Granted I haven’t used all of them, but they’re there). It can get hard to keep track of everything involved with a given app since components can be reused under multiple apps, etc.

BONUS: I also didn’t realize the extent to which I’d be using the Lightning Design System. I guess I’d just assumed (rather falsely) that using the ui/aura tags also would apply some sort of default style. This is not the case as near as I can tell, so I had to include LDS in my top level component. Again, I’m not sure why I was assuming I wouldn’t have to…but I assumed nonetheless.

Anyway, some of this might be way off but its what I discovered in my few short hours of exploration. Your mileage may vary.

:wq!