Hey all!

What did you do this week?

This week I worked on implementing Storybook for all the Icon components that are being generated. For being able to do this, I created a Storybook template using which I produced stories for each and every Icon Components. The demonstration of all the React components will become much more easier and understandable using storybook. It also provides instructions about all the different types of props that are supported by the Component. Other than this I have also started to work towards creating an npm package for VUE.js for EOS-Icons. It will be largely based on the React extension but a couple of changes according to the framework.

What is coming up next?

In the next couple of weeks I am going to be focusing towards building the VUE.js npm package. Will also finish the few test cases remaining in the React package as well.

Did I stuck anywhere?

There were a few problems while configuring Storybook for TypeScript but after going through the Storybook docs extensively I was able to properly implement it.

Hey all!

Half duration of the coding phase has almost come to end. With first evaluations starting soon, I have been readily engaged with my mentors in order to add more features and improve the current ones.

Testing using JEST

Why does this project require testing?

One of the most important part of a project is the tests that can be utilized to verify if or not the final build is working as expected. The advantage of having tests setup is that all of the future commits will have to go through the tests before getting merged in the codebase. This helps in making the final component package highly reliable.

Implementation of the tests

The decision for picking JEST as the testing framework was largely based on the ease of testing React components that JEST provides. In a early PR I added tests using snapshots which later turned out to be a not so good idea for testing. Later it was switched to a more robust way of testing by using the toHaveAttribute property for checking if the props are being applied to the SVG or not. The test suite consists of the 3 different types which are - filled, outlined and animated. This helps in verifying the state of the different types of SVGs.

Naming convention

The naming convention is something that will ultimately decide the user experience for using EOS-Icons React. Earlier PascalCase was being used which was not user friendly as it was difficult to edit out the icon name. Finally we are using SCREAMING_SNAKE_CASE as it makes the edit of the icon name as well as the theme a lot more simple. The current naming convention looks like this - EOS_ICON_THEME

Multi theme React components

Currently EOS icons React has icon component based on themes like animated / outlined / filled. Almost all of the filled SVG icons have a outlined variant and there are several use cases in which a project might use both the themes of a icon for example:- a rating website might have outlined stars initially ☆ and upon selecting those stars it will turn into a filled star ★ , In order to solve this issue we have decided to add this as a type of React component which will contain both filled as well as outline SVG, which will be changeable using the "theme" prop.

For the upcoming week I am planning to further improve the code base of the above mentioned changes as well as work on having a proper documentation that will help the user in using EOS-Icons React in a efficient way

Hey all!

What did you do this week?

This week I worked on implementing various different types of tests using JEST. There are a total of 3 different test suites for the 3 different types of icons (filled/outlined/animated). The tests are for checking if or not the produced React SVG component is being built in the right manner. The tests also contain a check for the various different props (color/size/rotation/flip). These tests will provide a setup in which we will be able to verify future addition to the React component template. I have added a new prop that is the flip prop. The flip prop consists of two different sub-props, that is horizontalFlip and verticalFlip. The flip prop required a function for fetching the values of scaleX, scaleY, TranslateX and TranslateY. I added a common function which will provide the React component with the correct transformation values depending upon the Flip prop. I have also setup the semantic versioning for the repo and published a early version of the package to npm, so that it is easy to test out the package that is being produced. EOS-Icons React. Upon testing the actual load that is being put by the package for using a single icon equals to roughly 1kb, Which shows that the package is working in a tree shaking manner (only the load of icon being used is put).

What is coming up next?

For the upcoming week I am going to work mainly on making a Documentation on "how to use Eos-icons React" as well as work on improving the code overall so that we can move towards a complete launch of the new package.

Did I stuck anywhere?

I got a bit stuck on the decision for picking out the best framework for testing out the package. With the help of my mentors I was finally able to implement all the tests using JEST.

Hey all!

The third week was full of implementing new features and learning about new concepts.

Script for scaffolding React components

During the third week of the coding phase I worked on the core logic of the project that is the Script responsible for scaffolding the various different SVGs into React components which are JavaScript as well as TypeScript supported. The script can be broken down into a few sub parts for easier explanation.

1. Fetching SVG data: The first step in order to build out the React component is to fetch the required SVG data from the .svg files. To do this i have used "fs" readFile functionality, it reads the required SVG file and returns the SVG data which is later on used for creating the component.
2. Props for modification: EOS-Icons natively supports a lot of modifications like color, size, rotation, Horizontal flip and vertical flip. My aim for this step was to add all these modifications as props for the React components. This was possible by simply modifying the SVG data that was earlier fetched in the last step. Currently I have added support for changing color, size, flip as well as rotation. In future more props can be added easily. The size prop and flip prop required extra logic, Basically EOS-icons currently has pre defined sizes like- "s","m","xxl",etc. I have added a size map in order to provide the user with these pre-defined sizes. Similarly i also made a common function for the flip prop incase the user wants to flip the SVG
3. Writting the components: The last step was to write all the various different SVG components under the destination src/icons/ along with a index.tsx file which is responsible for exporting all the components to the user.

Build commands

The project is completely build in TypeScript but in order to support JavaScript based React projects it required a TypeScript build config for producing files that are supported by JavaScript. The two main build commands produces the project in commonjs (cjs) format as well as esnext format under lib and es folder respectively. These are the folders which will be published on npm and utilised by the users.

Hey all!

What did you do this week?

After getting approval on the new implementation of EOS-Icons React package from my mentors I have started to push commits to main repository. This first pull request was regarding the initial setup of the project which contained the TypeScript configuration, Eslint configuration, package.json setting for publishing it over to npm and git ignore file for ignoring all the build folder. I also made a pull request for the setup of gulp for automating the process of fetching SVGs from "EOS-Icons" npm package. It required me to create functions for copying as well as deleting files.

What is coming up next?

For the next week i am going to be implementing the script for scaffolding React components from SVGs that will be fetched using gulp automation. The component will accept all the required props for modifying SVG as well as be Type safe for supporting TypeScript based React projects.

Did I stuck anywhere?

No, I did not get stuck anywhere but it required me to do a lot of research as well as learning for understanding how gulp works and how to use it for automation.