DEV Community: Eduard Andrei Capanu

Which E2E Tool to Use with React?

Eduard Andrei Capanu — Tue, 18 Jun 2024 14:34:04 +0000

When it comes to testing the end-to-end (E2E) integration of web applications, choosing the right tools is crucial to ensure comprehensive test coverage and optimal software quality.

I found this sentence online and it seems the most suitable given our context.

"If your test is difficult to write, your design is bad" - Randomly Software Engineer

That's why I decided to do a brief analysis, a bit closer, of some of the main E2E tools available on the market and their characteristics.

However, the entire analysis will be based on their compatibility with React.

After various analyses, the ones I found primarily used were:

Playwright
Cypress
SauceLabs
Testim
Puppeteer + Jest

Playwright

Playwright is an open-source automation library that allows testing web applications across different browsers and devices.
It is suitable for use with JavaScript React and offers a wide range of features for automating tests.

Strengths

Multi-browser and multi-device: supports testing on a wide range of browsers and devices, including Chrome, Firefox, Safari, and mobile devices like iPhone and Android.
Execution speed: it is known for its fast execution speed due to its efficient automation engine.
Powerful API: It offers a powerful and flexible API that allows writing complex and high-quality tests.
Snapshot testing: Supports snapshot testing to allow visual comparison of user interfaces.
Automated regression testing: Playwright's automated tests can be integrated into the CI/CD pipeline to check that the new code has not broken existing functionality.
Parallel testing for faster execution: It is able to run multiple tests simultaneously to reduce execution time.

Weaknesses

Steep learning curve: The learning curve might be steep for new users due to its flexibility and power.
Non-web applications: Playwright is specifically designed for web applications.
For native desktop or mobile native application testing, other tools would be more suitable.
Limited resources / Simple projects: Not suitable for simple web projects, the overhead of setting up and maintaining Playwright might not be justified.

Cypress

Cypress is a modern end-to-end testing framework designed specifically for web applications.
It offers a comprehensive set of features for writing, running, and debugging tests in real-time, including the ability to perform mocking.

Strengths

Ease of use: Cypress is known for its ease of use and simplicity in configuring and writing tests.
Real-time testing: It offers the ability to see the test in real-time during execution.
Simple debugging: It has built-in features for debugging tests, making it easier for developers to identify and fix issues.
Mocking and stubbing: Cypress offers built-in features for mocking and stubbing network requests.
Using the cy.request() command, Cypress isolates API interactions, facilitating a clearer separation between UI and API interactions.

Weaknesses

Limited browser support: Currently, browser support is limited to Chrome and Firefox.
Cypress's cy.request() focuses on response mimicking and does not provide detailed network interaction control.

SauceLabs

Sauce Labs is a cloud-based platform for automated testing of web and mobile applications.
It offers a wide range of features for running tests in parallel, testing on different browsers and devices, and integrating with continuous integration (CI) tools.

Strengths

Cloud Testing: Sauce Labs offers the ability to run tests on a wide range of devices and browsers in the cloud.
Compatibility: It offers excellent compatibility with a wide range of browsers and devices, including mobile devices.
Parallel and distributed: It allows parallel and distributed execution of tests, reducing overall execution times.
Integration with CI/CD: It is well integrated with continuous integration (CI) and continuous deployment (CD) tools.

Weaknesses

Cost: It may be costly compared to other solutions, especially if running tests on a large number of browser/device configurations.
Complex setup: Initial setup may be complex due to its cloud-based nature.

Testim

Testim is an AI-driven testing platform that automates the creation, execution, and maintenance of tests.
It uses AI to analyze application behavior and generate test scripts automatically.

Strengths

AI-driven testing: Testim uses artificial intelligence to help create, execute, and maintain tests automatically.
Ease of use: It is designed to be easy to use, with an intuitive interface that allows writing tests quickly.
Automatic test creation: It can automatically record user actions and generate tests based on these actions.
Test versioning: It offers built-in test versioning, allowing tracking of test changes and iterations.

Weaknesses

Limited manual control: Since it is AI-driven, it may not offer the desired level of manual control for some use cases, difficult to customize.
Cost: Testim may also be costly, especially for smaller companies or projects with limited budgets.

Puppeteer & Jest

Puppeteer is a Node.js library developed by Google that provides a high-level API to control headless Chrome or Chromium instances.
It is suitable for testing React applications, especially in end-to-end testing scenarios that require interaction with the browser's DOM.

Strengths

Full control over the browser: It provides a high-level API that allows full control over headless Chrome or Chromium instances. This enables to perform a wide range of tasks, including navigation, interaction with the DOM, form submissions, and more.
Support for modern web features: supports the latest web standards and features, making it suitable for testing modern web applications built with technologies like React, Angular, Vue.js, etc.
Integration with Chrome DevTools
Headless mode: can run Chrome or Chromium in headless mode, which means it operates without a graphical user interface. This makes it ideal for running tests in headless environments such as continuous integration (CI) pipelines.

Weaknesses

Limited cross-browser support: is primarily designed for testing with Chrome or Chromium browsers. While it can be used with other browsers via the WebDriver protocol, support for non-Chromium browsers may be limited.
Resource-intensive: requires the installation of a full Chrome or Chromium browser, which can consume significant system resources, especially when running multiple instances in parallel.
Steep learning curve: Puppeteer's API can be complex, especially for beginners. Users may need to invest time in learning how to use Puppeteer effectively for their testing needs.

In the next article, we will compare 2 of these technologies to see which one might be a better choice based on our context.
I hope the article was helpful, let me know if you know of other similar tools or if you use one different from those mentioned :)

End

I post once a week on React that I share via LinkedIn, follow me for more information and tips.

LinkedIn: https://www.linkedin.com/in/eduardcapanu/
X (Twitter): https://twitter.com/capanu2

How to use multiple files for configuring environment variables in React

Eduard Andrei Capanu — Mon, 06 May 2024 10:21:47 +0000

Sometimes I happened to have conflicts in the merge phase every time I modified those files that contained different properties for each environment.
For a long time I continued with this approach, resolving conflicts by hand thinking it was the right thing.

But looking online a bit I realized that there were many solutions, only that I didn't use any of them 😁.

In this article we will see how to configure and use different configuration files for environment variables.

Let's imagine we have 3 environments, one for development, one for system test and one for production.

A classic division on the code side would be to create a repository with 3 branches inside, one for each environment.

Now suppose we need to interact with backend services with different endpoints in each environment (different endpoints).
To do this, our 3 branches will probably never be completely aligned, right?

By implementing a multiple file system for managing environment variables we could create 3 files on each branch:

.env.dev
.env.sit
.env.prod

These files will all have a variable that we will call REACT_APP_BACKEND_URL (we use the REACT_APP prefix only because it is required by the library itself) and which will contain the value of the right endpoint to use.



REACT_APP_BACKEND_URL=dev-sample

In this way the application on each branch will have the exact same source.

The only thing we are missing is to start / build the app with one configuration file rather than another and change the endpoints within the app dynamically like this for example:



const backend_url = `https://${process.env.REACT_APP_BACKEND_URL}`

To solve the problem I will use the env-cmd library, thanks to it we can define via a script inside the package.json file which configuration file to read.

First, the library must be installed by launching:

npm install env-cmd

Let's add these 3 commands to the scripts tag, inside the package.json file.



{
  "scripts": {
     "start:dev": "env-cmd -f .env.dev react-scripts start",
     "start:sit": "env-cmd -f .env.sit react-scripts start",
     "start:prod": "env-cmd -f .env.prod react-scripts start"
  }
}

Thanks to the keyword -f we indicate the file from which to read the variables and then proceed with the normal start of the application.

This approach is very useful for several reasons:

We can test the new features with production services directly locally without having to change anything, just launch the command:

npm run start:prod

If you have pipelines for automatic build and deployment, you can create 3 other similar commands and decide to build with the right endpoints based on the pipeline launched.



{
  "scripts": {
     "start:dev": "env-cmd -f .env.dev react-scripts start",
     "start:sit": "env-cmd -f .env.sit react-scripts start",
     "start:prod": "env-cmd -f .env.prod react-scripts start",
     "build:dev": "env-cmd -f .env.dev npm run build",
     "build:sit": "env-cmd -f .env.sit npm run build",
     "build:prod": "env-cmd -f .env.prod npm run build",
     "build": "react-scripts build"
  }
}

You can implement hidden features for certain environments and simulate what is done via feature flags, directly on the client side. Giving only the application running in development and system test the opportunity to test a new feature, while also bringing the source into production.

If you liked the post or if you are interested in learning more about the topic, tell me below, so that I can make a video or similar articles based on the different use cases 😉.

ReactTS: Is React.FC really necessary?

Eduard Andrei Capanu — Mon, 06 May 2024 10:10:30 +0000

Today we often see the use of the FC (FunctionComponent) type in tutorials, courses, videos on YouTube, which deal with topics on React TypeScript.

At first I didn't pay any attention to it, it was something that everyone used so it was obviously fine to include it in my projects too :D.
Over time, by reading and learning more about the development of React applications through Function Components, I discovered that it is possible to return JSX, or in our case, TSX, even by not typing a function correctly.

interface IAppProps {
   name: string;
}
const App = (props: IAppProps) => <div>Hello {props.name}!</div>;

So the question arises spontaneously, what is the point of typing our component with FC?

There are a couple of advantages, that's for sure, let's go and see them together:
1) Our component function would become Type-Safe, it would give us an error trying to return a type other than a JSX.Element.

// no error is raised on the function
const App = (props: IAppProps) => `Hello ${props.name}!`;
// an error is raised if you accidentally return some other type
const App: React.FC = (props: IAppProps) => `Hello ${props.name}!`;

2) We have access to children implicitly within the props (Not everyone considers this to be an advantage, so let's see it as a 'feature' of React.FC)

/* 
without any additional interface we can access 'children' directly from props
*/
const App: React.FC = (props) => <div>{props.children}</div>;

We can immediately notice that the list is quite short, furthermore, by reading the React TypeScript documentation, we see that there are alternatives to what React.FC uses by default.

As an alternative to point 1, we can manually type the type returned by our component function.

/*
you can choose annotate the return type so an error is raised if you accidentally return some other type
*/
const App = ({name}: IAppProps): JSX.Element => {
   return <div>Hello {name}!</div>;
}

As an alternative to step 2, we can manually add children to the component interface like this:

interface IAppProps {
   name: string;
   children: JSX:Element;
}
const App = (props: IAppProps) => {
   return <div>
      Hello {props.name}!
      {props.children}
   </div>;
};

Also true is the fact that probably, if we were to use the children property, it would be better for us to implement React.FC, so we save ourselves the manual typing.

Ok, but are there any disadvantages to continuing to use React.FC?

1. Children passed even when you don't need it
The first thing I found is that children can be passed even if the component doesn't use them.

With React.FC:

// Don't want children
const Header: React.FC = (props) => { /*...*/ };
const App = () => {
   return <div>
      <Header>
        <span>Unwanted Item</span>
      </Header>
   </div>
}

Typing manually:

// Don't want children
const Header = (props): JSX:Element => { /*...*/ };
const App = (): => {
   return <div>
      <Header> // Will throw an error
        <span>Unwanted Item</span>
      </Header>
   </div>
}

2. Does not support generics
If desired, you can create components by defining generics in the interface

interface IAppPropsGeneric<T> {
  appList: T;
  name: string;
}
function App <T>(props: IAppPropsGeneric<T>) { /*...*/ }

Using React.FC there is no way to keep the generics in the types returned by the function.

const App: React.FC</*??*/> = <T>(props: IAppProps<T>) =>{/*...*/}

3. Does not work well with defaultProps
As is also described directly on the react-typescript site, there are known problems with using defaultProps using React.FC.

Let's take the example of a component that has a required input property and uses defaultProps to define its default value.
We will do an example without React.FC and one with, using the same interface.

type IHeaderProps = { title: string; }

Without React.FC things would be fine

const Header = ({ title }: IHeaderProps) => {
  return <div>
    {title.toUpperCase()} /* Safe since title is required */
  </div>
};
Header.defaultProps = { title: "Hello everyone!" };

const App = () => (<Header/>) 
/* Safe to omit 'title' since already has a default value */

Now let's see how it would behave using React.FC:

const Header: React.FC<IHeaderProps> = ({ title }) => {
  return <div>
    {title.toUpperCase()} /* Safe since title is required */
  </div>
};
Header.defaultProps = { title: "Hello everyone!" };

const App = () => (<Header/>) 
/* Error thrown here saying that propery title is missing */

Basically you can't use defaultProps to define i*nternally required* and externally optional properties.

The only way to get the desired result would be to use the default value directly in the destructoring on the input properties, and define the property as optional on the interface, like this

// Use of ? for optional parameter
type  IHeaderProps = { title?: string; }
// Add deafult value on destructoring
const Header: React.FC<IHeaderProps> = ({ title = 'Default Value' }) => {
  return <div>
    {title.toUpperCase()} 
    // Safe since title is required and has a default value
  </div>
};

const App = () => (<Header/>) 
/* Safe now cause the default value was defined internally */

But this doesn't solve the defaultProps problem, it just offers us an alternative :(

What to do then?
Finally, I leave you with the alternative to using React.FC:

const AppWithFC: React.FC<IAppProps> = (props) => { /*...*/ }
const App = (props: IAppProps): JSX.Element => { /*...*/ };

All this to say that it is not strictly necessary to use it, there are alternatives to returning valid JSX.
And if you want to use children, you can add input properties to the interface or use React.FC, however, I would like to point out that the documentation discourages their use nowadays.

Using React.FC, children will most likely be removed from implicit parameters on props, from version 18.0.0 onwards of @types/react.

I hope I have given you some ideas :)

I understand that there are all kinds of materials online and often not everything we see being used en masse means it's the right thing to take into consideration.

So I greet you and if you liked the article I would like to know your opinion on the topic.
Do you use React.FC within your projects? :D

PS: I used it and still use it a lot, but don't tell anyone, thanks :)

Redirect Your Online Success with Rebrandly: The Power of Customized Links

Eduard Andrei Capanu — Thu, 02 May 2024 14:49:55 +0000

I am a person obsessed with personal branding.

Even though mine is not yet at the level I would like, I am always looking for new ways that can boost my services, my image, and my voice.

In this article, I present to you Rebrandly, an application and service that can help us primarily with the branding of our links.

Rebrandly helps us in a completely customizable way to brand our links 100%.

As we can see in the image below, through the platform, we unlock the full potential of short links, leading our brand where we want and giving our clients a clear idea of the service we offer.

Image source here

During my use of the service, I noticed the following positive aspects that really helped me in sharing my materials and content through the web.

An easy and intuitive interface to use
Link management capable of implementing and modifying up to the most advanced options, such as:
- UTM Builder
- Traffic Routing
- Retargeting scripts
- OpenGraph metadata

A clear view of analytics related to clicks, country/device, and platform of origin
Great way for mass import of my links
The possibility to create a page called 'Link Gallery' that displays our links in one place.
Definitely useful for sharing, for example, on Instagram along with our various social channels or services that we offer.

These are just some of the features I had the opportunity to delve into, but the system also offers other innovative features plus the opportunity to integrate it with external services or access internal APIs for development purposes.

I hope the article seemed interesting to you and that you will consider Rebrandly to scale up your brand in the online world.

If not, I would be curious to hear your opinion about it and discover what alternatives you have chosen for branding your links.

Follow me on LinkedIn for more information and tips: 🔹Eduard Capanu

React: You Might Not Need Another Library

Eduard Andrei Capanu — Sat, 27 Apr 2024 14:18:49 +0000

In the React ecosystem, it's easy to fall into the temptation of integrating a myriad of libraries to enhance functionality and simplify development.

However, this often leads to an overload of dependencies and more challenging code management.

In this brief reflection, we'll explore the concept that in many situations, you might not need to add another library.

React offers a robust and flexible set of features that enables developers to build complex applications without the need for external libraries.

It's essential to carefully evaluate whether adding a new library is truly necessary or if the same results can be achieved using React's native capabilities.

One of the primary reasons to limit the use of external libraries is the dependency on third parties.

Each time we add a new library to our project, we increase the risk of compatibility issues, security vulnerabilities, and complications in the update process.

Additionally, excessive library usage can bloat the application bundle, slowing down loading times and increasing browser resource consumption.

Instead of seeking external solutions for every problem we encounter, it's beneficial to explore React's native capabilities and make the most of its features. Often, there are ways to achieve the same results using techniques already available in React, such as state management with useContext and useReducer, custom hooks, and optimized rendering patterns.

Of course, there are cases where adding an external library may be justified, such as when dealing with complex or specific functionalities that are not easily implementable with React's native features.

However, it's essential to carefully evaluate alternatives and consider the long-term effects on code architecture and maintainability.

In conclusion, the next time we're tempted to add another library to our React project, let's take a moment to reflect on whether it's genuinely necessary. We may discover that React's native solutions are more than sufficient to achieve our goals, reducing code complexity and improving application maintainability.

Follow me on LinkedIn for more information and tips: Eduard Capanu | LinkedIn

React Developer Tools — So it really helps sometimes!

Eduard Andrei Capanu — Tue, 15 Mar 2022 19:20:41 +0000

I'm that kind of person who, as soon as I start to delve into a new topic / framework / library, I go and do research on everything that could make studying or putting it into practice easier.
In fact, I don't even know the extensions I downloaded in the first days of studying React, I'll just tell you that they were more extensions for React Native than for ReactJS 😁.

Among all this plethora of tools I also downloaded React Developer Tools. (Link for Chrome Web Store, Firefox Add-ons for Firefox, and Microsoft Edge Addons)

Obviously months went by without me using it at all, I didn't understand its potential and usefulness.
And it is precisely for this reason that, after 1 and a half years now, I have decided to bring you some of the really useful features of this extension.

Functionalities

Identification of an app developed in React
By visiting a web page you have the opportunity to see whether it was written in React or not.
Let's take for example a sample page I made: Google Keep Clone Basic.

Just look at the color to understand that the app was written in React and uses a production build.

Let's see an example of a page that doesn't use React instead.

The exact same thing for local applications too.

As from the message presented to us, we see that for those apps that use React, we have 2 new tabs available.

Components tab
By opening the extension you have the opportunity to see how the application is actually structured and identify, for example, a problematic item on a list.

You can pass properties to test how components work with different inputs or change the state of hooks such as useState().
Very useful in case you have non-visible values such as the 'isLoading' parameters.

A step forward for debugging for sure, enough with console.logs at every point of the application 😁.

By inspecting a component you can also observe which part of the application rendered it, showing the components in cascade.

In addition to data inspection and manipulation, the tab comes with some interesting settings.
It gives us the possibility to hide certain components from the list, if the app is very complex and large, change the theme, stop on wranings or decide to print all the information relating to a component in the console.

How many times have you had to print the input props to a component and write and rewrite console.log(props)?😁

Profiler tab
Thanks to this tab we can identify and optimize the performance of our components, once started you will be listening to all the modifications and changes within the app.

Initially the profiler could only be activated once the application had been loaded, thus losing the initial render, which is often the most problematic one.
The issue was resolved later, with the introduction of the 'Reload and start profiling' button.

Which will refresh the page and start the profiler automatically.
Let's see how it works though.

The profiler will display a list of all items along with the loading time of each.
They will then be colored differently based on the time taken and you will have the opportunity to identify those who take the longest to render their children or themselves.
You can also notice if a component is rendered more than once, very useful for discovering superfluous renders.

Debugging React applications can be difficult, especially when users encounter problems that are difficult to reproduce, so I think the extension can be very useful for several use cases.
Both during development and later for performance optimization.

If you liked the post, let me know in the comments, and if you would like to learn more about the topic, tell me below, so that I can make a video or an article in which I actually explain how to best use the profiler and the components tab based on different use cases 😉.

5 Ways to Get Started with Azure

Eduard Andrei Capanu — Fri, 21 Jan 2022 13:29:15 +0000

My boss told me to start using Azure…

Ah no, this is not my story, you are certainly not interested in this, or are you? (let me know in the comments and we'll see how to solve it 😁)

Most likely if you have arrived here it is either because you are interested or because you have to start studying Azure out of necessity.

I understand you, there are many cloud services and you want to know more, such as Amazon Web Services, Google Cloud etc. (just to name the most famous).
Well, let's say that Microsoft also has its fairly large market share, but we're not here to talk about that today, so let's get started.

The platform offers over 100 cloud services and integrates seamlessly with other Microsoft products, many tech enthusiasts feel pressure to understand cloud platforms like Azure.
But for beginners, the cloud can seem complex and overwhelming.

This article will offer a complete guide to getting started with Azure.

Let's quickly learn the basic Azure terminology

Azure Active Directory (AD)
Also known as tenant, it is a set of network services based on Microsoft's cloud and is intended to help users access resources.

Subscription
A subscription simply refers to the billing agreement between Microsoft and the customer.
Each Azure subscription comes with a directory, but each directory can contain multiple subscriptions.

Resource
The term resource refers to the individual services offered by Azure, such as a virtual machine or a SQL database.
However, the resources must be linked to a resource group.

Resource Group
It typically manages resources that need to be protected, managed, and deployed as a whole.
Resource Groups can help you both organize your resources and create a safety boundary where necessary.

1. Microsoft's Azure Fundamentals documentation (completely free)
One of the best ways to approach Azure is to start with their documentation.
Microsoft offers many well-structured paths that can help both those who find themselves faced with a cloud platform for the first time and those who already have a good foundation in it.

I recommend starting with Concepts of Azure fundamentals Part 1 and continue to part 6.

2. Courses on Pluralsight (paid)
If you are looking for video lessons and are good at English, Pluralsight is a platform specialized in distance learning to enrich your skills and be able to complete any project.

The best path to start with to delve deeper into Azure is definitely Microsoft Azure Fundamentals.

At the time of writing the article the subscription costs €26 / month and €275 / year.

3. Video on Youtube (free of course)

On Youtube we really find so many useful videos, the problem is precisely the amount of content we find.
I thought I'd make a list of videos that have helped me personally and that I've seen more than once.

a. Introduction at Azure (with Fabio Biondi and Andrea Saltarello / Italiano) - Introductory video that explains a little about how Azure is structured internally, both in terms of resources and price, with practical examples too.

b. How to create an Azure account (English)

c. Create your first Web App on Microsoft Azure (English)

d. Azure Fundamentals course by freeCodeCamp (English) — Overview of the topics covered in the exam to obtain the AZ-900 certification.

4. LinkedIn Learning (paid — free)
LinkedIn Learning sometimes surprises me, it is a platform that offers courses + exercises and a sometimes exceptional community.
As soon as you finish a course on the platform you have access to chats where you can interact with those who have seen the same course/video. Furthermore, you have the opportunity to help and exchange points of view on the topic.

The only negative point is the cost, which is quite high, but you can always try the free one-month version, in which you have full access to everything. It's definitely worth a try.
Furthermore, at the end of each finished course you receive a LinkedIn badge which certifies the completion of the course.

The video I liked the most was the one about preparing for the exam Azure Funtamentals, in the end it included all the key points you need to know to be able to start taking the path towards the cloud in the Microsoft world.

The link to the course here.

My Medium / LinkedIn profile obviously 😁 (free) I often make/share posts on Frontend topics related to the Microsoft world, new technologies and reflections on work.

My LinkedIn profile.
My Medium profile.

Going on the profile costs nothing 😊, if you liked the article I would be happy to hear your opinion in the comments.

7 Signs you're a good programmer

Eduard Andrei Capanu — Sun, 09 Jan 2022 16:14:56 +0000

I always wondered if I was a good programmer or not, the fact is that most developers are 'average'.

For example, I'm not a good developer, but I try to improve my skills every day and put them into practice.

Starting from this need, I wanted to find out how I could improve and what leads a developer to be above average.

After reading various articles I was able to make a brief summary of the things that seemed most interesting to me.

7 Signs You're a Good Developer

1.Try and experiment before asking
Instead of going for help at every obstacle, a good programmer first tries to solve the problem on his own.
This prepares him to face problems in the future regardless of their difficulty.

Sintoms

You create and work on private/personal projects to better explore new features or to experiment with certain cases
Think about alternative solutions with the aim of solving the problem encountered

2.You have a lot of patience
Sometimes it may happen that the environment in which you work is noisy or that due to many tasks / commitments or activities to carry out, you are a little mentally stressed.
It must be remembered that a good programmer must have patience to fight with these situations and associate priorities with his activities.
Most good programmers are tolerant and humble, attributes that help them fit in with the rest of the team, and produce fantastic work.

Sintoms

You can predict a bug before running the code (it means you paid close attention to the code you wrote before running it)
You don't know how many times your colleague went for a coffee or to the bathroom because of your concentration

3.You are hungry for knowledge
Developers who learn for their own interest are the best.
Because consuming knowledge is an art and you cannot defeat hunger with pressure.

Since our modern world is being filled with new technological innovations every second, a good programmer should have strong domain knowledge and should know multiple languages.
There's little point in learning everything you need to know about a specific technology to be a good programmer.

Since every technology present or coming in the future is nothing more than an evolved variant of something previous, if a programmer's skill set has continuously evolved over time and has an encyclopedic understanding, there is really no need to worry .

Sintoms

You focus less on promotion and money, and more on learning new things for yourself
You always complain about product delivery times

4.You teach
The best way to learn something is to know how to explain it to others, which is why teaching helps you understand a topic better and more deeply.

Sintoms

You enjoy sharing new skills with others
You like to bring conversations about new technologies/tools
Sometimes reply on StackOverflow
You help others solve their problems

5.You are always looking for perfection
Perfectionist developers often focus on performance, architecture, code cleanliness etc., they know that greatness will come after them if their work is perfect, and this is why they obsess.

Sintoms

Would you be willing to do a substantial code refactor shortly before the deadline
You always complain about product delivery times
You don't like to compromise when it comes to code
Check what you wrote 10 times before launching the application / software / product

6.You are not attached to a specific tool/framework
In the end, the language and the framework are just tools.
For a good programmer it is more important to first define the needs of the product and its architecture, and then continue with the technology that brings more advantages compared to the requirements.

Sintoms

Assume your own code is the source of a bug before blaming the compiler, library, or operating system
You don't care or depend 'too much' on a certain framework / tool
Don't get involved in “language wars”

7.You are not emotionally involved in the code
We often get too attached to our code and sometimes we regret deleting/updating certain parts we've worked hard on.
A good programmer is not emotionally attached to his code and makes necessary changes when needed without any regrets.

Sintoms

You have no commented code within your software / application / product
You refer to it as “the code” rather than “my code”
You don't get defensive when someone tells you your code needs to be updated.

Conclusions

There are actually many other signs of being a good programmer besides these 7 mentioned in this article.
But surely the first thing you need to do is start trying and putting it into practice.

Little by little you will get closer and closer to your goal 🙂

How to create a Power Apps Component Framework (PCF)

Eduard Andrei Capanu — Mon, 09 Mar 2020 11:56:37 +0000

Hi everyone, my name is Eduard and together with a dear friend of mine,
Newton Urbanetz, we were trying last day to create our first PCF (PowerApps Component Framework).

I must say that, to be a Microsoft component I expected to be documented in a much better way. In fact, some parts are not fully explained, I also found it difficult to find information in a single Microsoft Docs.
With this article I hope to fill these empty spaces, to put all the information
in one place and make everyone understand how to create their first PCF.

So, let’s start this path together !

We will go through 3 steps, firstly we will download all necessary files, then we will see how to create a simple static grid, and then publish it.

What do you need to create a PCF project?

Firstly we need to install the Power Apps CLI, which gives us access to creation / update and deploy functions of a custom control component.
To do this, Microsoft gives us this guide. But let’s do it together !

1) We need to install Node.js and together it will come also installed NPM.

What is Node.js?

A framework that allows you to create server-side applications in Javascript, using an engine, called V8, which was made by Google, but this is not important for us, at least not now :)

NPM instead is a package manager (Node.js Package Manager) tool that
allows you to include, remove and update libraries within project.

2) Without the .NET Framework version 4.6.2 it is not possible to use the Power Apps CLI.

To install it you can either go to the Microsoft website and download the Developer version. Or open Visual Studio Installer, select ‘Individual Components’ and then choose .NET Framework 4.6.2 SDK & .NET Framework 4.6.2 Targeting Pack.

Once you have selected, click on ‘Edit’ at the bottom right.

3) Download the Power Apps CLI

In order to create a PCF project you need to have a version of Visual Studio equal to or greater than 2017 !

Once we have followed these 3 simple steps we can start setting up our project

How to set up a PCF project?

1) Create a folder called MyFirstPCF

2) Then, open your favorite command prompt, which can be the classic CMD or other console emulators like CMDER.

Open the folder created, using the command ‘cd ’. It’s time to launch the command shown below:



pac pcf init --namespace <specify your namespace here> --name <Name of the code component> 
--template <component type>

With this command we have created a Power Apps Component Framework (PCF) project in our folder.
In the namespace param you can enter whatever you want, in the name param we will enter the name we want to give to our component, the important thing is to understand the types of templates available. There are currently only 2 templates for model-driven apps (Field and DataSet) and only one for canvas apps (Field).

Since Microsoft talks about the Field in the documentation and my need was to create another type of template, a grid for example, I found myself in difficulty.

So let’s choose DataSet and see what happens:



pac pcf init --namespace MyFristPCF --name GridComponent --template dataset

Once the command has been executed, we must make sure that we have installed all the necessary dependencies, so execute:



npm install

We are ready to start, we have created and configured our project and our component, open component in your favourite editor. I will use Visual Studio Code.

You should be able to see this files:

Creating a static grid and start it in local

Let’s create the syle of our grid, create a folder named ‘assets’ and copy this css there:

global.css



#customers {
font-family: "Trebuchet MS", Arial, Helvetica, sans-serif;
border-collapse: collapse;
width: 100%;
}
#customers td, #customers th {
border: 1px solid #ddd;
padding: 8px;
}
#customers tr:nth-child(even) {
background-color: #f2f2f2;
}
#customers tr:hover {
background-color: #ddd;
}
#customers th {
padding-top: 12px;
padding-bottom: 12px;
text-align: left;
background-color: #4CAF50;
color: white;
}

Now we need to comunicate to our PCF that the css that we want to use is the one present in global.css. To do this we will modify the ControlManifest.Input.xml, this file is important and we will talk about it later in my next post :), for now add in the ‘resources’ tag our css reference



<css path="assets/global.css" order="1" />

You should have something like this:

Open index.ts to write our grid code and implement it in PCF. There are some methods already presents like updateView, getOutputs, destroy and init

updateView: will be fired when any property of our control changes

getOutputs: called by framework when the data related to control changes

destroy: called by framework when component is removed from DOM tree

init: initialize the control. Here you build your control with the HTML
elements that would be rendered on CRM forms / views

We want that our grid loads at the same time with the CRM page, so the code will be centralized in the init method.

Init accept in input some variables like context, notifyOutputChanged, state and container

context: The entire property bag available to control via Context Object; It contains values as set up by the customizer mapped to property names defined in the manifest, as well as utility functions.

notifyOutputChanged: A callback method to alert the framework that the control has new outputs ready to be retrieved asynchronously.

state: A piece of data that persists in one session for a single user. Can be set at any point in a controls life cycle by calling ‘setControlState’ in the Mode interface.

container: If a control is marked control-type=’standard’, it will receive an empty div element within which it can render its content.

I will explain better the posibilities that this 4 variables are giving to us in a future post, but for now i think that we can focus on the container.

Let’s start code (not so much, for now :D)

First of all, create a container of HTMLDivElement type into our GridComponent class:



private mainContainer: HTMLDivElement;

I have created a simple variable named gridHTML that contains our table html as bellow:



const gridHTML = `<table id="customers">
<tr>
<th>Company</th>
<th>Contact</th>
<th>Country</th>
</tr>
<tr>
<td>Alfreds Futterkiste</td>
<td>Maria Anders</td>
<td>Germany</td>
</tr>
<tr>
<td>Paris spécialités</td>
<td>Marie Bertrand</td>
<td>France</td>
</tr>
</table>`

Now, we need to create a <div> to put our table in, and then ‘inject’ the HTML into the page:



// Create main table container div
this.mainContainer = document.createElement("div");
this.mainContainer.id = 'GridContainer';
this.mainContainer.innerHTML = gridHTML;
container.appendChild(this.mainContainer);

Let’s see what happens, write and lunch command bellow to build and start the project in local.



npm start

You should be able to see the result by navigating on http://127.0.0.1:8181/

As you can see, Power Apps component framework provide us a special interface of debugging, it really helps if we want to debug with real data or if we want to see if our component is responsive or not.

Ok, so… I think that it’s the moment to publish this great grid :))

First, navigate to our ‘GridComponent’ folder and create a new folder named ‘solution’. To publish a PCF we need a solution to connect with. Into the solution folder write the following command:



pac solution init --publisher-name <publisher name> --publisher-prefix <publisher prefix>

I have created a new publisher on my environment and i will use this one, you can use yours or the default one.

Since my publisher name is ‘edu’ I will write something like this:



pac solution init --publisher-name edu --publisher-prefix edu

You will be able to see that some files were created into the folder, we have created an empty solution, now we need to connect our project to this empty solution. To do this you must run the following command from solution path.



pac solution add-reference --path <project path>

In our case, the project path is ‘ C:\MyFirstPCF’. After that we have a solution with our component inside. Next step is the connection with our organization, to do it I will use this command here:



pac auth create --url <your organization url>

Before publish , we need to build it, a new folder named ‘out’ will be created in our project folder, to do it you need to be in your component path, in this case ‘C:\MyFirstPCF\GridComponent’ and run the following:



npm run build

To publish our component we need to use Developer Command Prompt, both version 2017 or 2019 are fine. This cause Power Apps CLI needs MSBuild.exe and Developer Command Prompt already comes with it.

From our project path run bellow command:



pac pcf push --publisher-prefix <publisher prefix>

And that’s it, we should be able to see our PCF published now, so navigate on our solution, entity, choose the one that you want, I will choose Account

And from ‘Controls’ tab add control like bellow:

Then choose it for Web disponibility, save and publish. Let’s see what we have :)

We have do it, I hope that this wasn’t difficult for you. I think that is enought for this post, surely I have already bored you :D

I want to thank you for getting so far, this was my first article, I accept advice and I hope you enjoyed it. Next time I would like to explain better the real functionality of the PCF and how to interact with the data coming from the context, how to configure our manifest and how to debug with real data in local.

See you next time !