
## A little background

Our source control story started many years ago using a tool popular at the time in the .NET circles called Source Gear vault. This tool worked well in the beginning due to its simplicity, resemblance to the file system and a reasonably user-friendly UI. However, we hit a few issues with using this tool and with how it influenced our source control management strategy:

- Branching is not a central concept in this tool and was not easy to use
- The software is proprietary and is not very popular thus lacking support from large CI systems and other productivity tools
- Lack of community to find issues/best practices
- The application was not implemented correctly from the beginning making it difficult to change
- High licensing costs
- No rigid process of managing commits

We looked for alternative options there were not many. Git seemed like the best version control system available. It seemed to address all the issues mentioned above and presented a multitude of options for implementation of a successful source control management strategy.

Now we had to choose a platform to implement Git. Due to the high sensitivity of the software development area that we work in, we could not use a third party hosted solution, thus, unfortunately, eliminating Bitbucket or Github. We had to find an on-premise solution instead. As we are a .NET development house, we have decided to trial Team Foundation Server (TFS) with Git. TFS is a compelling software suite that is installable on-premise, and that has all the bells and whistles required for source control management in addition to Continuous Integration, Project management tools and other productivity services. Unfortunately, we found the licensing model to be very complicated and expensive and the User Interface to not be intuitive. Also, it did not demonstrate high performance, but that might have been due to our internal misconfiguration. So we looked further and discovered Gitlab.

Gitlab is an open source web-based Git, repository manager. Gitlabs UI resembles the user interface of Github and offers pretty much all the functionality provided by Github. The Community edition of Gitlab is distributed under the MIT license and can be easily installed on a Linux box. The tool also comes with inbuilt Continuous Integration and Issue tracking. The company behind it has a team of around 150 devs (as of December 2016) and over 1400 contributors (https://en.wikipedia.org/wiki/GitLab). It integrated well with lots of third-party services and had excellent documentation. After presenting this solution to the team, we have reached an agreement to go ahead and implement Gitlab as our version control system.

Now that we had a tool, I wanted to make sure that we pick a valid and consistent strategy for our software version control. We have started by looking at Gitflow.

## About Gitflow

Gitflow is a source control workflow pioneered by Vincent Driessen at nvie. It acts as an extension to the “Feature Branch” workflow by providing an opinionated branching model centred around releases. There are numerous articles available online providing more details on this workflow; the critical part is that it focuses on having a master and development branches. All the work is done in feature branches. When the work is completed feature branches get merged back into develop branch and once a feature or a set of features are ready for release a release branch is created of the develop branch. The release branch can only then have commits to fix some bugs before release as well as changes to documentation and other pre-release tasks. Once the release is ready, it gets merged into the master and back into the develop branch as essential changes might have been done to the release branch. Once the version is released, the master branch gets tagged with the release version number, and the release branch gets deleted. Finally, if a fix to the application is required it can be done using Hotfix branches, these branches are created of the master branch and then get merged into both master and develop branches once completed [source](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow).

We have tried to use the classic Gitflow model, but unfortunately, we have hit a few issues:

- High focus on continuous delivery: Our processes did not allow us to continuously deliver changes to our products and required us to maintain multiple version of the same product. This was making it hard to use the classic Gitflow workflow with ephemeral release branches. We were struggling to keep the master always in a releasable state thus potentially introducing bugs in production.
- Maintaining ‘develop’ and ‘master’ branch: Let’s agree that merging and resolving conflicts is a laborious and time-consuming task. Doing this on two branches made it even harder. As we have a small development team having this burden on myself to maintain two branches did not work well, merge request processing was slow and we did not have confidence in the master branch.
- Complexity: The work-flow introduces complexity that probably is fine in bigger development teams but causes severe friction and efficiency impact in smaller ones.

After hitting these hurdles, I have decided to take a step back and look at alternative flavours of Gitflow. I still believe that the methodology is excellent it just needed a few tweaks to match closer to our development work-flow. First I looked at
[Github Flow](https://guides.github.com/introduction/flow/index.html).

## Github Flow

Github Flow is a simplified version of GitFlow where you only have one master branch, and you manage all the development in feature branches which then get integrated into the master using pull/merge requests. This methodology is simple and robust and has been adopted by numerous companies successfully, but it still relies on the master branch to always be deployable and does not offer tools for managing multiple versions of the application. Finally, I stumbled upon Gitlab Flow.

## Gitlab Flow

Gilab Flow offers two paths. First, one using a “production” branch, so all the development happens in feature branches that are merged into the master and when they are ready for release they get merged into the “production” branch. This way you have the benefits of having a branch that is stable and can be released at any point and the convenience of using “master” for all the current work. There are variations of this approach where you can add more environment-related branches like a “pre-production” branch. When a feature is ready to be deployed, it can be merged from master into the pre-production branch and then once the code is ready to go live the pre-production branch gets merged into the “production” branch. Hotfixes would be developed on feature branches and then merged into the master and pre-production. Essentially you create a one-way data flow for all the software changes.

The last approach offered by Gitlab flow is using “release” branches. Each release branch should have a minor version number and would use master as the starting point. These release branches are created as late as possible in the development cycle to reduce the amount of time that has to be spent in propagating the changes to multiple release branches. After this release branch is announced, only critical bug fixes are done on this branch. Bug fixes are done in feature branches, then merged into master and then cherry-picked into the release branch. This is done to ensure that changes do not get forgotten to be merged into master. The title of this approach is ‘upstream first’. According to Gitlab documentation both Google and Red Hat practice this approach [more info](https://about.gitlab.com/2014/09/29/gitlab-flow/).This was the actual solution that matched the closest to what we were looking for. Now we had a master branch that we could work on via feature branches, multiple stable releases that we could patch and release into production whenever necessary. An approach to making isolated changes with a clear path and minimal room for error. I have outlined the process in the diagram below, and it has been working very well for us so far.

![](/images/blog/my-git-story/gitlab-flow.png)

## A few tips I found useful.

### Squashing Commits

When working on feature branches, I tend to check-in my code multiple times to have a remote backup of the progress. Unfortunately, this created a somewhat messy git commit history. Squashing the commits allows merging all of the commits into a single one. Gitlab allows specifying whether the commits should be squashed in the specification of the merge request

[https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html).

### Naming your branches

Picking a correct naming convention for branches was quite confusing to me and took me some attempts before I have figured out a clear and concise way of naming the branches. Here is the template that I have chosen:

**[Type of Branch]-[Product]-[Description]**

Type of Branch — this describes whether the branch is a ‘Feature’ a ‘Release’ or a ‘Patch’ (aka Hotfix)
Product — as we build multiple products from the mono repository this contains the name of the product or ‘Generic’ for generic Features
Description — describes the purpose of the branch, it could contain the feature id, or a general description if we are using this branch for working on multiple issues

## Conclusion

We hope to move to one production branch in the future once our CI processes evolve but for now, Gitlab flow with release branches offers us the best flexibility and reliability compared to other ways of managing our code. I recommend to everyone to check out Gitlab and Gitlab flow and would like to thank the Gitlab ream for providing such a great peace of software.


This post is aimed at describing how and why I have implemented the gitflow process at my current work place.

My Git Story


JavaScript frameworks have become an integral part of our web development toolkit. The world of JavaScript frameworks has grown bigger and more complex. However as of today we see a phew major players like React, Angular and Vue cementing their place in the industry. All of these are powerful complex technologies with a steep learning curve. Committing to either of the frameworks creates a major dependency for your organisation and a requirement for a specialised work force capable of efficiently using the framework of choice. In addition going with one of these frameworks locks you in the Frameworks ecosystem making it more challenging to take advantage of developments in other JavaScript environments. As we know, the world of web development is an ever changing environment and committing to a certain technology without a backup plan can have serious implications for the future.

Today I would like to explore with you one possible solution for how we can introduce a "backup plan" for "safeguarding" the future of our Frontend code and potentially take advantage of developments across different ecosystems. This potential Solution is to build Web Components using our chosen JavaScript framework. Lets explore some of the options that we have today for the 3 top JS frameworks.

First lets look at what are web components and why, as responsible web development professionals, we should be interested in them.

## What are Web Components?

Web Components are a collection of different technologies allowing web developers to create reusable HTML\JavaScript components with their functionality completely separated from the application that uses them. Very importantly Web Component technologies are **standardized** technologies for building reusable custom components thus paving a way for creating framework and browser agnostic custom components for the web.

Web components encapsulate the following 4 technologies:

- HTML imports - a way to import html documents into other documents
- HTML templates - a way to create portions of html code on the page that will not be rendered initially but can be used by JavaScript code later in the applications logic
- Custom elements - native APIs for building your own HTML elements
- Shadow DOM - provides the ability to encapsulate the logic of your component and the styles completely away from the rest of the application

## Why Web Components?

One of the reasons most of us got excited with using JS frameworks such as Angular and React is the ability to split our application into simple reusable components. Web components promise to give us the ability to do this natively without worrying about third party dependencies, framework feature deprecation or employee specific skills. Web components allow to wrap UI components into isolated bits of UI logic via Custom Elements with Shadow DOM technologies and HTML templates making it possible to safely mix and match different component libraries. This opens tons of possibilities for expanding your audience when you want to share your work and significantly reduces complexity for implementing your work by other people. Finally web components are native technologies that don't require third party dependencies which should help in reducing your JavaScript library footprint and improve performance of complex UI components.

## Browser Support

As of today Chrome, Opera, Firefox, Safar and Edge fully support web components.

![](/images/blog/web-components/web-components-support.png)

Source: [webcomponents.org](https://www.webcomponents.org/)

Most of the browser support limitations can be overcome with poly-fills on which we have to rely anyway when using React, Angular or Vue with older browsers.

## Web Components limitations

There are a number of limitations with using pure web components.

### Slow pace of standard adoption

As we know from the past, Web Standards can be slow to adopt. This might introduce a delay in development of new features in this space.

### Mixed browser support

The variation in browser support has significantly improved and today, if you are building components for "Evergreen" browsers, you don't even need to think about it. However if you are building applications for the enterprise, which might still need to support older versions of IE, you should carefully analyse the browser support limitations that you might have to face.

### Relatively complex and verbose API

The API is still quite verbose and might be hard to grasp.

### Requires going back to pure Vanilla JavaScript for building complex UX

Building Web components using Vanilla JavaScript can be hard but it could be a positive side effect as it could help "Framework Developers" get back to JavaScript roots and write more conscientious and performant code.

## Using Web components with React, Angular and Vue

The good news is that all of the three JavaScript framework Titans have support for using web components out of the box.

In React you can directly use web components in your jsx templates

```javascript
class HelloMessage extends React.Component {
  render() {
    return (
      <div>
        Hello <x-search>{this.props.name}</x-search>!
      </div>
    );
  }
}
```

Source: [React Docs](https:\reactjs.org\docs\web-components.html)

In Vue you can use web components by adding them to the ignored elements list (https:\alligator.io\vuejs\vue-integrate-web-components)

```javascript
Vue.config.ignoredElements = ["x-ticking-paragraph"];
```

In Angular you can use web components by enabling support for the CUSTOM_ELEMENT_SCHEMA (https:\alligator.io\angular\using-custom-elements)

```javascript
@NgModule({
  declarations: [AppComponent],
  schemas: [CUSTOM_ELEMENTS_SCHEMA],
  imports: [BrowserModule, FormsModule],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}
```

Now that we know that we can safely use web components in our existing single page applications it is time to figure out how to build them with a minimal impact to our time and efficiency. This is where I have discovered that we can actually use our favorite framework to build Web Components.

## Using React, Vue and Angular to build web components

The example component is a simple "likes counter" with 2 buttons "Like" to bring the likes counter up and "Dislike" to bring the likes counter down

First lets have a quick look at how to build this simple Web Component natively. I have used stackblitz to demonstrate how to do it. You can follow the code or check this Mozilla article for step by step instructions

Embed the following here
https://stackblitz.com/edit/web-components-article-js?file=index.html

In the next part we will look at how to build web components with react, Angular and Vue

## React

Next lets build the above component using React.

https://stackblitz.com/edit/web-components-article-react?embed=1&file=VoteCounter.js

As you can see nothing special here, we are extending the React.Component class, adding local state to store the "totalCount" value and adding like and dislike methods to handle the buttons functionality. All then gets rendered using the render function. We then have an App Component that renders our VoteCounter component

Things get a bit more complex when it comes to wrapping React component as a web component. React does not have a native way of wrapping React Components as Web Components. I have only found one library that claims to be capable of doing it. The library is called react-web-component developed by spring-media.
Here is how you would convert the above component into a web component using this library:

```
install the react-web-component package
```

```
npm install react-web-component
```

Now create a React component using the code from the previous stages
Import the react-web-components library
Add some web component specific life-cycle hooks
Wrap the component using the method from the React web components library
Now we need to build this component as a standalone JS file
Ado the build steps

This library did indeed create a webcomponent but I have hit some big limitations, one of them not being able to pass props from HTML to the react component. There are multiple issues reported on this problem #123, #234, #456. Unfortunately the library does not seem to be actively maintained and these issues have been open for quite a while now.

Another approach to use web components with React is to actually use React inside the web component. This will require React to be loaded alongside the web component.

## Vue

Vue supported the concept of converting Vue components into native Web Components for a while and the process is relatively straight forward.

Vue has a native library called @vue/web-component-wrapper. The library requires vue cli V3:

- Create a new project using the cli

```
vue create web-component-article-vue
```

- Create a new component

```
src/components/RsvpCounter.vue
```

- Use the `@vue/web-component-wrapper` library in the main.js file to wrap the component as a webcomponent
- Use the window.customElements.define function to add the web component to the component registry
- Final step is to package the Vue component as a standard webcomponent. We can use the powerful vue cli for this by running the following command

```
vue-cli-service build --target wc
```

**Note**: for the last step I have added a dedicated main.wc.js file containing just the code required for the web component and I have added the command was an npm script
Note: When running the web component in dev mode styles for the wrapped web component will not work. Everything works fine after building the web component

https://vuejsdevelopers.com/2018/05/21/vue-js-web-component/
.........

## Angular

Angular version 6 has introduced a way to build web components using the @angular\elements package. Later versions of Angular introduced further improvements to @angular\elements. Here is how you would build a web component in Angular 8

This is how we would build the above component using @angular/elements

Setup a new project `ng new angular-app`
Generate a new component `ng g c RsvpCounter`
Add the @angular/elements library `ng add @angular/elements`
Add the @webcomponents/webcomponentsjs library `npm install @webcomponents/webcomponentsjs`
Wrap the Angular component as a webcomponent in the AppModule constructor

```javaScript
export class AppModule {
  constructor(injector: Injector) {
    const custom = createCustomElement(HelloWorldComponent, {injector: injector});
  }
}
```

Now add the web component to custom elements

```javascript
customElements.define("app-hello-world", custom);
```

Similar to the customElements issue in using react in web components, you might require a polyfill for custom elements to work.

```javascript
@webcomponents/webcomponentsjs`
```

Simply add the polyfill to your polyfils.ts file

```javascript
import '@webcomponents/webcomponentsjs/custom-elements-es5-adapter.js';`
```

The above steps will make the component usable in Angular components allowing things like dynamically injecting the component using vanilla JavaScript.

Now lets look at how to package our component as a a standalone web component.

First lets add a new module that will only contain our web component

```javascript
[Example code required]
```

Now lets add a new config to angular-json for building this new module

```json
[Example code required]
```

Now lets add a build command that will perform the following:

- Build the angular app specifying the new module as the 'main' file
- Concatenate the built files
- Output the final build to a webcomponent folder

```sh
ng build angular-app --prod --output-hashing=none --main=helloworld.wc.module.ts && cat dist/angular-app/runtime.js dist/angular-app/polyfills.js dist/angular-app/scripts.js dist/angular-app/main.js > preview/angularapp.js
```

**Note**:

For windows users there is a node implementation of `cat ` [nodecat](https://www.npmjs.com/package/nodecat).
Alternatively you could also use this package [ngx-build-plusngx-build-plus](https://github.com/manfredsteyer/ngx-build-plus) that extends the Angular CLI and provides a mechanism for outputting single js bundles

..

The Angular team has been doing a lot of work in further improving efficiency, and the bundle size produced by the Angular rendering engine to a point where a hello world App now builds to a bundle that is only 27KB in size. But the most exciting feature is the new version of Angular rendering engine code named Ivy. It has been introduced as an optin feature in Angular 8. The engine has been refactored to leverage full use of tree shaking techniques making it possible to only include the bare necessary parts of your application down to a rendering instruction level. This makes the final bundle even smaller giving even more room for producing standalone web components using Angular.

# Conclusion

As we can see all the three JavaScript framework giants support Web Components one way or another, it is clear that Vue and Angular see it as an integral peace that will help the frameworks stand the course of time. Vue had good web component support since version 3 of the Vue CLI and has the most straightforward and easy to use tooling. The Angular team has been putting a lot of efforts into this area as well and significantly reduced the configuration required for building web components. React can easily consume web components but is not really fit for building them. It seems that the React community does not feel like web components are important to them so i don't think we will get native like support any time soon.

Who knows maybe one day all of the components we will be building will be web components. So why not start experimenting now and have one more skill in our portfolio for helping us deal with the ever changing web development landscape.


Building Web Components with your favorite JavaScript framework

Blog Posts

My Git Story

Building Web Components with your favorite JavaScript framework

My Git Story

Building Web Components with your favorite JavaScript framework