DEV Community: Justin J

Create An Angular Library And Consume it locally (with debugging)

Justin J — Fri, 17 Sep 2021 08:20:48 +0000

Angular project calling a library project. To View the code, here's the github repo.

This tutorial will detail how to:

Create an angular library
Create a component in that library
Export that component for use in an application
Create an angular application
Import the local component library
Access debugging for the library from the main application.

This tutorial assumes a basic understanding of Angular/ web development and using the command prompt.

If there is just a code snippet, that assumes you are in the console.

Creating the shared library

Create a folder called 'AngularTutorial', then a folder in that called 'code' somewhere on your file system.
cd to the starting folder code. e.g. cd C:/AngularTutorial/code
ng new ngx-my-shared-libs --create-application=false
cd ngx-my-shared-libs
ng generate library my-shared-components
cd projects\my-shared-components\src\lib (full path {repo}\code\ngx-my-shared-libs\projects\my-shared-components\src\lib)
ng g c TestView (creates new component called TestView)
Find public-api.ts under code\ngx-my-shared-libs\projects\my-shared-components\src\lib
Add a line for the new component (see final line of example below), so the file now looks like the following

/*
 * Public API Surface of my-shared-components
 */

export * from './lib/my-shared-components.service';
export * from './lib/my-shared-components.component';
export * from './lib/my-shared-components.module';


export * from './lib/test-view/test-view.component';

[10]. Export the view component in the module (code\ngx-my-shared-libs\projects\my-shared-components\src\lib\my-shared-components.component.ts):

import { NgModule } from '@angular/core';
import { MySharedComponentsComponent } from './my-shared-components.component';
import { TestViewComponent } from './test-view/test-view.component';



@NgModule({
  declarations: [
    MySharedComponentsComponent,
    TestViewComponent
  ],
  imports: [
  ],
  exports: [
    MySharedComponentsComponent,
    TestViewComponent /* NEW! */
  ]
})
export class MySharedComponentsModule { }

[11]. Open command prompt at code\ngx-my-shared-libs and run ng build --watch.

Importing Into The Angular Project

In a new command prompt, cd back to the top level i.e. {repo}/code.
create a new sample app using ng new ngx-sample-app --skip-tests . Answer the init questions as you wish (I said yes to routing, then CSS for style).
cd ngx-sample-app
now we need to reference the local library using npm install with a local link. Remember to link to the dist folder.

npm install "file://../ngx-my-shared-libs//dist//my-shared-components"

[5]. Import the component into your application module (code\ngx-sample-app\src\app\app.module.ts)

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { MySharedComponentsModule } from 'my-shared-components';


@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule,
    MySharedComponentsModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

[6]. Open up code\ngx-sample-app\src\app\app.component.html

Delete the default contents and update like so:

App Component

<lib-test-view></lib-test-view>

[7]. Go to the angular.json in ngx-sample-app (code\ngx-sample-app\angular.json) and add preserveSymLinks to the biuld options

Sample below shortened for brevity.


"architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "preserveSymlinks": true,
            "outputPath": "dist/ngx-sample-app",
            "index": "src/index.html",
            "main": "src/main.ts",

[8]. To this point, we can actually build everything, but we can't actually debug those libraries, so let's go ahead and fix that. In angular.json (code\ngx-sample-app\angular.json), update serve to include options for debugging libs too.

Again, shortened for brevity - starting at line 89 in my sample $projects.ngx-sample-app.architect.serve:

"serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "sourceMap": {
              "scripts": true,
              "styles": true,
              "vendor": true
            }
          },

[9]. In the command prompt for the app ({repo/code\ngx-sample-app>}) run ng serve.

[10]. Visit https://localhost:4200 to view the results.

[11]. In chrome, you can now press F12, then go to sources, Ctrl+P to search files and type 'test-view' to get to the test-view component.

Could I be a 10x-er?

Justin J — Wed, 14 Aug 2019 14:09:43 +0000

A while ago, the following tweet bought up the old conversation about 10x
developers. Devs so good, they're worth 10 of the "poor class" regular developers.

10x engineers

Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.

OK, here is a tough question.

How do you spot a 10x engineer?
— Shekhar Kirani (@skirani) July 11, 2019

I haven't had the chance to write recently so it's not as topical, but this stuck in my mind and I thought I should write.

As a junior dev. I longed to be one of those "rockstars" that frantically fired away at the keys and only produced gold 🏆.

10+ years in lets see how it's going?

1. 10x Engineers Hate Meetings.

1. 10x engineers hate meetings. They think it is a waste of time and obvious things are being discussed. They attend meetings because the manager has called for a "Staff meeting" to discuss the features and status.
— Shekhar Kirani (@skirani) July 11, 2019

Yes! That's me. I really hate meetings. Especially if they're about "use of the office fridge" or "what should we name our project".

Except... I like scrum meetings. They can be really handy and I'm convinced they save time overall. Also, it's good to know how we're doing as a team.

Sometimes other people in the team have found some really smart solutions you could employ yourself later down the line.

Oh, I like some client meetings too. Especially ones where the client actually appreciates the effort you put in for them, or work in a constructive way to get requirements right.

Hmm... Ok. A mixed start. I'll go with his comments being just about the fridge and move on.

2. Highly irregular timings.

2. Timings in the office for 10x engineers is highly irregular. They tend to work when very few folks are around. If there is a crowd or all-hands meeting, they are not visible. Most of them are late-night coders and come late to the office.
— Shekhar Kirani (@skirani) July 11, 2019

Errr. I have a kid. Try having irregular timings when you have a school run to sort. Maybe 10x-er's can't be (good) parents too?

One of the best developers I've ever worked with started work bang on 8am every day. So I'm just going to dismiss this one to keep myself in with a chance.

Minus points for me here.

3. Black Backrounds

3. 10x engineers laptop screen background color is typically black (they always change defaults). Their keyboard keys such as i, f, x are usually worn out than of a, s, and e (email senders).
— Shekhar Kirani (@skirani) July 11, 2019

Black background = +1 For me. It's much better for your eyes. If you're not doing it, you really should. Also - invest in a good monitor! Look after your eyes!

Before you white backgrounders start ranting - I used to be a white backgrounder - and now I can't go outside without sunglasses. I look stupid outside in February rain with sunnies on, so why risk it?

Am I better at coding now I use a black background?

Nope.

I'd say the biggest improvement has been from getting a good nights sleep, but that doesn't sound very "rockstar", does it?

4. 10x engineers know every line of the code that has gone into production

4. 10x engineers know every line of the code that has gone into production. If a QA or support folks alert an issue, they know precisely where the fault (or bug) is and can fix the same in hours vs days
— Shekhar Kirani (@skirani) July 11, 2019

Having worked for a near startup (2 coders), I would say once you get to 3 coders, nobody knows everything going into a code base. Usually, you only know immediately "precisely where the fault is" if you created it 🤫.

There is usually someone who gets to know the product better than everyone else, but that isn't necessarily the 10x-er.

I made a point of getting to know the orignal product best in that company. The result was; when new cool stuff came along; I was stuck with the old product, because I was "quicker at working on it". I had to fight hard to be allowed onto the new stuff.

That is not a situation I'd like to be in again any time soon, so until I'm 10 years off retirement, I don't even want a +1 here.

5. Full Stack + Doesn't do UI

5. Most of the 10x engineers are full-stack engineers. For them code is code, they don't care whether it is front-end, back-end, API, database, serverless, etc. I have rarely seen them doing UI work.
— Shekhar Kirani (@skirani) July 11, 2019

Full stack = +1 for me. Though pretty much all software is going to need a UI at some point, right?

In fact, I'd say that's what end users value over almost everything else? If you had amazing software, but the background was green with orange buttons all placed in the middle-right of the screen - people would hate it. Making great UI's is a real skill (one I wish I had) and should not be looked down on IMO.

6 Thought into code

6. 10x engineers can convert "thought" into "code" in their mind and write it in an iterative fashion. Given a product feature, they can write that entire feature in one or two sittings of 4 to 6 hours with a caffeinated drink without distraction.
— Shekhar Kirani (@skirani) July 11, 2019

This just comes with practice and a good requirements breakdown.

Write an entire feature in 2 sittings - well that just depends on how big the feature is doesn't it?

If the new feature requirement is "Add a new textbox and save the data to a simple app.", then yes. I could do that with time to play on the interwebs too!

Another +1 for me (albeit with wiggle room to make it so!)

7. Rarely look at help documentation

7. 10x engineers rarely look at help documentation of classes or methods. They know it in memory and can recall from memory. They write code at the same ease as writing English. No breaks, no pauce, just type.
— Shekhar Kirani (@skirani) July 11, 2019

I'll make a little aside here. When I started my first job, I started trying to work out a problem myself. My boss came in. After explaining what I was doing he yelled "I'M NOT PAYING YOU TO SATISFY YOUR FUCKING EGO! GOOGLE THE FUCKING ANSWER!".

While his point could have been put a bit nicer, he was right. There's almost nothing you will face that someone else hasn't faced before. I'm sure I can google/stackoverflow some things quicker than I could write them, let alone solve the problem for. So I Google. I Google a lot.

My thoughts here are learn the basics and google the rest.

When you need to work out how to find if a double is a prime number or some kind of tricky date function - don't even bother trying to work it out. Google the answer, take the accepted answer on StackOverflow. Copy.Paste. Move on.

To meet the criteria here, 10x-ers will to have to be in the far end of a normal distribution for A LOT of knowledge.

Here's about where I am. NOTE: I'm not trying to claim any number of x's anywhere here. My point here is really there's a whole lot of stuff I couldn't do without a lot of Googling!

As you can see, my chances are shot about now, but stick with me - we're near the end.

8. Always learning.

8. 10x engineers are always learning new frameworks, languages ahead of everyone in the company. They are not afraid of anything new. If there is something new (e.g. blockchain) they gobble up, setup, experiment before anyone is getting started.
— Shekhar Kirani (@skirani) July 11, 2019

Yes. I love the new stuff....

But one thing to remember is that this may change at some point. Nearly every developer gets to a point in life where they just can't be faffed chasing
shiny ways of doing what they already know. The good thing to know is that I've worked with several people like that and they are still very good developers.

One is so important to a company, they even have him insured!

The other thing with "always learning new stuff" is there comes a point where the learning serves no benefit. I've learnt so much over the years that I've either never implemented, or have used but no longer holds any weight. Even valid technologies can become obsolete. I'd really recommend learning what you need to know rather than leaning to "know everything" as I used to.

Forgotten/ Obsolete learning: AngularJS 😭, Knockout JS, Visual Basic, MATLAB, Web Forms, Classic ASP, Flash... the list goes on.

9. Poor Mentors

9. 10x engineers are poor mentors as they can't teach others on what to do OR parcel the work. They always think "It takes too long to teach or discuss with others, I would rather do it myself." They are also poor interviewers.
— Shekhar Kirani (@skirani) July 11, 2019

The greatest developer I've ever worked with was also a phenomenal mentor to me. Being a grumpy unsociable arsehole doesn't make you a great developer.

In fact, one of my greatest satisfactions has been mentoring someone who had zero experience to being a professional developer. I'm immensely proud of it.

I'm going to class the guy as a tool (as if I handn't already). I'll take the negative points with pride 🏅.

10. Don't hack and dont document

10. 10x engineers don't hack things. They write quality code and know exactly how the code has to evolve, and have a mental model of overall code structure. They write at most one design document, and the rest is in the code.
— Shekhar Kirani (@skirani) July 11, 2019

There's a difference between not knowing you're hacking and knowing how to code, yet still implementing a hack.

Short term i.e. "Right now" hacks are usually quicker than doing it properly and are sometimes required in a scrape/ Priority 1 bug scenario.

Of course, it can royally screw you over later, but if your boss threatens to sack you if you dont do a 3 week job in 2 hours, or the system is unusable without fast action, you hack it. Don't be afraid to implement a short term hack/ "fix". To my mind, a good company will let you code it properly later - a bad one won't.

Rather than “git blame” I would like to see “git I did the best I could with the tools and organizational structure available to me so just give me a little space and time and it will get fixed eventually”
— Scott Hanselman (@shanselman ) March 4, 2019

If you really want to screw over your teammates - DONT DOCUMENT.

The mantra that good code documents itself is complete bollocks.

Undocumented configs are an accident waiting to happen.

Also, I have been in the situation of understanding a bit of code completely, but not understanding WHY it is as it is. The why is important, because when it comes to changing it you are risking damaging the scenario it works for. I think every developer has at some point changed code, only to find they've broken another scenario.

Almost nobody has 100% code coverage on their unit/ integration tests.

Also, if you document, when people ask, you can just politely say "Read the document", so you get to spend more time coding and less time telling people stuff you've already told them.

Yet again - the guy's a tool. I document where possible.

11. Move around?

11. 10x engineers rarely job hunt or move out of the company. They move out because you make their life miserable with the process, meetings, training, and other non-value-added activities. If you come across them, hold on to them. Celebrate them.
— Shekhar Kirani (@skirani) July 11, 2019

People who are that good are ambitious tend to move regardless imo. There can be a big mistake in thinking committed people are loyal.

I used to think you had to move companies every 3 years. I was told it when I started and I stuck to it for a while.

I've been at my current company 5 years and am really happy. I'd have been happy at my previous company if I hadn't moved and just matured a little. I know some great developers who have stayed with a company from their first job.

12. One of the comments which I'll add as I feel it sums up a stereotype.

Great thread! Some more pointers:

- They know vi and use vi keys everywhere
- They don't use default browsers or IDEs (they would always be experimenting)
- They would talk hours and try to convince you about their choice of browser or IDE
- Prefer to do things from command line
— Sarang Lakare (@SarangLakare) July 13, 2019

Heck, Just like over 2 million people, I CAN'T EVEN EXIT THE DAMN THING.

-10 points for me.

Conclusion

When I was a junior dev, I longed to be "great".

I worked with a colleague in my first job who "acted 10x". Managers loved him but, in fact, his code was a big steamy pile of horse shit and was always late. As one of my friends/colleagues put it "If there's regions in your methods, your methods are too long". Still, because he put on a good show, people believed his own hype.

For a while, I tried to act in a similar way as I thought you had to act like that to be respected.

These days I don't care. Clearly, I fail this chaps criteria quite comprehensively.

I am what I am. I'm a nice person, who likes being in a team, who would like to think he is "good at his job".

That describes millions of us coders and theres nothing wrong with that.

In a world where the media makes out that Elon Musk is single handedly writing all the ML on Tesla's while making rockets and 10 years olds are writing all the stuff you do but better, it's easy to feel inferior.

Unlike some people, I'm not in denial that 10x-ers exist. I think there probably are a very small number of people who can be that great.

If their attitude fits this persons sterotype though, don't look up to them. Pick people who can be great, but not make you feel inferior as a result.

Go do it, people. #BeTheLuck for someone right now. I'm lucky my 5th grade teacher thought to loan me the Apple ][ that day. That my dad sold our van to get me a C64 later that year. That I bumped into @scottgu 11 years ago and he offered me a job. Go #BeTheLuck.
— Scott Hanselman (@shanselman ) February 27, 2019

I hope if you've got this far you feel this has given you hope. It's completely OK not to be some sort of "superhuman coder" and you really don't need to fit these misguided stereotypes.

As long as you enjoy what you do, that's all that matters IMO.

I wake up every day looking forward to going to work. I hope it stays like that for years to come.

"How did you learn everything you know about Kubernetes?"
Me: pic.twitter.com/Tfz3FjBqU1
— Daniele Polencic (@danielepolencic ) August 6, 2019

I changed career to software development without a CS degree, Ask Me Anything!

Justin J — Wed, 01 May 2019 07:57:57 +0000

Creating this in hope I can help someone (you?) thinking of making the jump to Software Development. Go ahead, ask me anything :).