DEV Community: Nitzan Hen

Help me get familiar with Tailwind CSS

Nitzan Hen — Wed, 29 Jun 2022 12:11:19 +0000

Hello!

Are you an expert on Tailwind CSS? a more casual user or beginner? or simply curious about it like me?
In any case, I'd like your help!

I'm working on a huge new version for Agrippa, which is essentially an open source tool for generating frontend components without the boilerplate (kind of like supercharged snippets, but even greater 🤩).
Seeing as Tailwind is already used in many teams today and it's only becoming more and more popular, I thought it could be beneficial to many if Agrippa had first-class support for it - and it's a great opportunity to learn more about a trending tool, too 😄

My immediate question is, therefore, more about the practical patterns of tailwind than the idea of it, and most particularly - in a project that uses Tailwind CSS, what does your typical component look like? what are your "must-haves" for such a component? is there any boilerplate that could be automatically generated for you, saving you time?

Of course, it wouldn't be interesting to limit the discussion just to that, so let's talk about Tailwind in general:

What sold you on Tailwind?
Which of Tailwind's features do you use most and which do you not use?
Do you have any tips to share about using it?
Do you struggle with any of its aspects?

Personally, I always thought Tailwind's alternative method to writing CSS is problematic, and would cause problems down the line in terms of clarity, scalability and maintainability. However, seeing enough talented people in large teams praise it convinced me to reconsider!

I'm really hoping to hear everyone's experiences and bits of wisdom about Tailwind!

If you prefer talking on Twitter, let's discuss it there!
Or, if you'd like to contribute to Agrippa's effort to support Tailwind directly, we'd love to hear your voice on our GitHub issue!

Thank you and have a great day!

Agrippa 1.4 is out 🎉🎊

Nitzan Hen — Wed, 09 Feb 2022 20:15:23 +0000

The fourth minor version of Agrippa, the React component CLI, is finally out!

Once again, Agrippa's community has grown a lot since the release of the previous minor update, v1.3.0, back in December. Agrippa has grown by over 230 stars since the previous release - in absolute terms, that's our biggest growth yet!

Releasing a new version is always a good opportunity to express my deep gratitude to everyone using Agrippa, and especially those of you who've given your feedback, suggested features, or opened other issues on our GitHub repository. You're the best!

If you're not using Agrippa, join us! Read the Getting Started guide or visit us on GitHub.

v1.4.0

We have some exciting new features released in v1.4.0:

New terminal UI 🎨

Agrippa's terminal UI has been revamped! it should now be more informative, a lot cleaner, and especially much more ✨aesthetic✨.

As an example:

Styled-components 💅

Agrippa now supports styling with styled-components! This is actually the second issue opened for Agrippa, and it's been open for quite a while now. It's truly nice to see it finally implemented. To check it out, use the value styled-components for the styling flag.

tsPropsDeclaration

TS users can now select between interfaces and types for component props declarations.
For more info, see the docs on tsPropsDeclaration.

New post-command variables

Two new variables, <ComponentName> and <component-name>, can now be used with post commands.
The first is the generated component's name in pascal case (e.g. NiceButton), while the second is in kebab case (e.g. nice-button).

Dependency cleanup

Two packages that Agrippa has been using up to now, but hasn't really needed to, were removed, and Agrippa should now be a little lighter.

That's pretty much it! We've already begun to work on the next features for Agrippa. Our main focus in the near future is on implementing test file generation, further expanding Agrippa's flexibility to suite custom use-cases, and more.
That being said, we're always on the lookout ideas for new features and improvements, so if you have one - please share it with us!

To get started with Agrippa, read the Getting Started guide or visit us on GitHub.
Your thoughts and feedback, as always, are most welcome.
If you've found a bug with this release, or want to suggest a new feature, please submit an issue.

Cheers!

Getting started with Agrippa, the React CLI

Nitzan Hen — Sun, 30 Jan 2022 11:06:36 +0000

TLDR: Agrippa is a CLI for generating React components with ease. By typing three words into the command line in your project, you can generate a whole new component - including a dedicated directory, styling files, an index file, etc. It takes a few seconds to set up in any React project, a couple of minutes to learn, and saves you time and effort from the get-go.

To get started, visit Agrippa on GitHub. If you'd like to know some more, stick around:

Why Agrippa?

You might be wondering, what are Agrippa's advantages over writing components by hand, copying & pasting from template files, or using a snippet tool (in VSCode, for example)? The short answer is that using Agrippa is much more efficient, and the generated result is both more flexible and more complete.

Let's walk through it: in terms of time it takes to set up a component, typing a short command into your favorite terminal is orders of magnitude faster than writing components by hand or manually copying & pasting from template files (e.g. on your PC). As for snippets, the time to create a basic component using a snippet may not be much higher than typing a short command, but when you factor in creating a directory, index file, and styling file for the component alongside the React code itself - having a command doing it all for you is quicker and more convenient.

But there's a second, more important advantage for Agrippa over snippets - flexibility. This is actually my main motivation for creating Agrippa! If you or your team have a favorite stack which is used in all of the projects you work on - a few snippets might do the job well enough for you. But, React has a diverse ecosystem, and you might easily find yourself working in many different environments with different tools.
As a concrete example, let's say in your dev life you come across both JS and TS projects, four different styling solutions (e.g. SCSS, CSS, JSS, styled-components), two different export types (named & default), and two different component declaration schemes (const & function). Any combination of those is valid, so to account for all of them you'd need 4*2*2*2 = 32 snippets. And that's before taking into consideration React Native projects, different prop declarations (JSDoc, prop-types), etc. You end up working more on your snippets than your project!

And sure, you could get around with a smaller amount of snippets by making them more generic. But, then they lose their flexibility, and you find yourself "fixing" every component generated with a snippet, so that it actually fits into the projects' stack.

Again, compare that to writing a 3-4 word command into the command line, and getting a much better result. A compelling option, right?

Setting up Agrippa

Getting started with Agrippa is dead simple, regardless of project size. The minimal requirements to using it is simply installing it, using npm i -g agrippa.
When run in a project, using agrippa gen <component-name>, Agrippa automatically determines most of the options it needs to run effectively - this includes whether the project is using Typescript, whether it's a React Native project, etc.

Typical output for agrippa gen (v1.4.0+):

Using a config

Options that aren't detected automatically (e.g. which styling solution code to generate) can be passed through the command line. However, to avoid having to type the same options over and over, using a config is recommended. A config is a plain old JSON file, named .agripparc.json, which typically sits at the root of your project. It can be generated by calling agrippa init. Then, you can add your options, and Agrippa will read them whenever it is run!

In most projects, you'd add two-three options to the config - the styling solution you use, a baseDir in which your components are usually generated, and, occasionally, a postCommand, which is a command that's run after Agrippa successfully generates a components.

A typical .agripparc.json config file looks something along the lines of:

For the complete list of options that Agrippa supports, see The Complete List of Generation Options on the wiki. For more info about baseDir, see Using baseDir and dest. Finally, for more info about post-commands, which are one of the main features that make Agrippa as flexible as it is, see The Post Command cookbook 🍲.

Final notes

That's it! Agrippa has an ever-growing community around it, and I hope you'll join it too! To get started, visit Agrippa on GitHub.

I'd love to hear your thoughts and feedback on Agrippa (or on this post in particular). Thanks for your time, have a great day!

Why we used Docker for testing

Nitzan Hen — Wed, 29 Dec 2021 21:11:09 +0000

Perhaps the greatest lesson I've learned from creating Agrippa so far is just how important tests are. Of course I knew they were important before - everybody does - but it's so easy to just push it aside and focus on more exciting code, or write some perfunctory tests that don't really, well, test anything. Eventually, however, slacking off on testing comes back to bite you; for me, luckily, it did when things were only getting started, but the point was clear - writing good tests is a top priority.

A challenging tool to test

For Agrippa, however, writing good tests is far from trivial - it's a CLI for generating React components based on a project's environment (dependencies, existence of config files, etc.), as well as an optional .agripparc.json config. In other words, a lot of its work is reading & parsing command-line arguments, looking up and reading certain files, and its end result is writing additional files. All of those are non-pure side effects, which are difficult to cover properly with just unit tests.

Additionally, because Agrippa's defaults greatly depend on the project's environment, it's easy for tests to return false results because of the presence of an unrelated file or dependency.
This is best explained with an example: when run, Agrippa auto-detects whether a project uses Typescript or not, by the existence of a tsconfig.json file in it. However, Agrippa itself is written in Typescript, which means there's a tsconfig.json file at its root. As a result, whenever running Agrippa in any sub directory of the project root, it generates Typescript (.ts/.tsx) files unless explicitly told otherwise. And, if tests were stored, for example, in a test folder in the project repository - they would all be tampered with (at least, those where files are looked up). A similar problem is cause by the existence Agrippa's own package.json.

With this in mind, when planning the implementation of testing I decided on these two key principles:

There need to be good integration tests which test the process - including all of its non pure effects (parsing CLI options, reading files, writing files) - from start to finish, under different conditions and in different environments.
The integration tests have to be executed in a space as isolated as possible, due to the process being greatly dependent on the environment it's run in.

The second point is where you can see the need for Docker - initially, I tried implementing the tests in a temporary directory created by Node and running the tests there, but this turned out to be too much work to build and maintain, and the created directory could still theoretically be non-pure.
Docker, on the other hand, is all about spinning up isolated environments with ease - we have complete control over the OS, the file structure, the present files, and we're more explicit about it all.

In our case, then, running the tests inside a docker container would get us the isolation we need. So that's what we went with:

The solution

# Solution file structure (simplified)
test/integration/
├─ case1/
│  ├─ solution/
│  │  ├─ ComponentOne.tsx
│  │  ├─ component-one.css
│  ├─ testinfo.json
├─ case2/
│  ├─ solution/
│  │  ├─ ComponentTwo.tsx
│  │  ├─ component-two.css
│  ├─ testinfo.json
├─ case3/
│  ├─ ...
├─ integration.test.ts
├─ jest.integration.config.js
Dockerfile.integration

The end solution works like so:
Integration test cases are stored under test/integration, in the Agrippa repository. Each case contains a testinfo.json file, which declares some general info about the test - a name, a description and the command to be run - and a directory solution, with the directories and files that are meant to be created by the command. The test/integration directory also contains a Jest config, and integration.test.ts, which contains the test logic itself.

When the test:integration Node script is run, it builds a Docker image from Dockerfile.integration, located at the project root. This is a two-stage build: the first stage copies the project source, builds it and packs it into a tarball, and the second copies & installs that tarball, then copies the test/integration directory. After building the image, a container is created from it, which runs the tests inside.

The testing logic is non-trivial, too. It scans the test/integration directory for cases, and creates a test suite for each (using describe.each()). The test suite for each case starts by running the case - scanning the solution directory, running the agrippa command, then scanning the output directory - then compares the two results. A case is considered successful if (and only if) both solution and output have exactly the same directories, the same files, and the content in each file is the same.

Further improvements

So far, the solution has been working well. The script takes longer to run than a standard testing script, because of the time it takes for Docker to set up (about 60-70 seconds if Docker needs to build the image, a few seconds otherwise). However, it's simpler, more robust, and safer than implementing a custom solution (with temporary directories, for example), and adding new test cases is easy and boilerplate-free.

The output (shortened for display purposes) looks like this:

One problem with the implementation, unrelated to Docker, is about using Jest as the testing framework. As it turns out, Jest is limited when it comes to asynchronous testing, and combining a dynamic number of test suites (one for each case), a dynamic number of tests in each, as well as asynchronous setup before all tests (scanning test/integration for cases) and before each test (running the case) simply doesn't work out.

When I get to it, I hope to switch to a different testing framework - Mocha looks good for this particular scenario, and seems fun to get into.

Conclusion

Since Agrippa is greatly sensitive to the environment it's run in,
we needed complete isolation of our testing environment for the tests to truly be accurate. Docker provides exactly that - and therefore we turned to it. The solution using it took some time to properly implement - but it turned out well.

What do you think? do you have an improvement to suggest, or something to add? I'd love to hear from you!
Thanks for your time.

Agrippa 1.3 is out 🎉🎉🎉

Nitzan Hen — Sat, 04 Dec 2021 21:46:55 +0000

The third minor version of Agrippa, the React component CLI, is finally out!

Since v1.2.0 came out, Agrippa has seen tremendous growth - counting the difference in stars on the GitHub repo, for example, we've grown by 120% (154 stars) over the course of just over 40 days!
More issues are also being opened (and closed!) on GitHub, too.

This is a good opportunity to say that I'm truly grateful for everyone who have tried Agrippa out and joined the community; I'm delighted to see Agrippa growing and being used, and I'm super excited for it to grow and improve further in the future.

So, thanks everyone!
If you're not using Agrippa, join us! Get started here.

As for the new version, this one was in the works for longer than the previous two; integration tests, in particular, were a challenge to implement.
Version 1.3.0 brings the following changes:

The separate-index scheme: Agrippa's default component directories structure now separates the main component file, which contains the component's declaration and logic, from the index file, which is the component directory's entry point. Previously, Agrippa placed the component logic under the index file, which resulted in less files overall - but made it harder to distinguish between components in IDEs, which hurt the developer experience. Generated components should be easier to work with now! Many thanks to @wickedpuppy for suggesting this feature.
For more info, check out separate-index on Agrippa's docs.
Support for React Native: Agrippa now supports React Native projects!
Furthermore, it can auto-detect a react native project by having the react-native dependency in its package.json,so you don't really need to configure anything in a typical project! Of course, styling with React Native's StyleSheets is also supported (and, for React Native projects, also enforced).
For more info, check out reactNative on Agrippa's docs.
Agrippa is now covered by integration tests, as well as more unit tests.
Integration tests were a challenge - since Agrippa is all about reading and writing files automatically, testing it effectively requires setting up and running in a completely isolated environment! We ended up combining Docker, Jest and some custom code to create a pretty sophisticated solution, and it works quite well.
More tests are on the way, but the tool already has pretty good coverage.
Tweaks & Bug fixes:
- props=ts can no longer be used without the typescript flag; additionally, the typescript flag now implies that props=ts (of course, this is overridden by any value set by the user).
- The allowOutsideBase check is now skipped if baseDir is not specified.
- Fixed a bug where --children would generate <div>children</div> instead of <div>{children}</div> in the JSX template.

Your thoughts and feedback, as always, are most welcome.
If you've found a bug with this release, or want to suggest a new feature, please submit an issue.

Have a great week!

You DON'T need these to be a web dev

Nitzan Hen — Wed, 01 Dec 2021 00:18:43 +0000

"If you don't know all of these, don't call yourself a web developer", followed by some list of web dev related terms. Have you encountered one of these posts before? I come across them every once in a while on social media.

These sorts of divisive claims bring about nothing but toxicity to our community, and only alienate the junior developers who are new to it. Especially for the profit of some traffic on Twitter or elsewhere, it's despicable.

They paint a completely wrong image of the web dev scene, too - being a web developer is much more about the perpetual process of self-improving, learning new tools & technologies and experimenting with methods to combine them in the best way, rather than knowing some constant list of terms (which are often occasionally useful at best). And, built on top of the open-source industry, the web dev industry is one of the most welcoming industries out there, to programmers of any caliber.

So, to be perfectly clear - you don't need to know closures, the event loop, hoisting, etc. to be a web developer. The same goes for non-niche concepts & technologies - you can be a good dev without knowing Docker, FP/OOP or cloud computing, for example. Knowledge is always good to have, so if you're not familiar with them you should aspire to learn them sometime, but you can also be a damn good developer without them.

I think my personal journey is a good indication to this point: I was met with web development close to three years ago, when I began my mandatory service; beforehand I knew some Java, from school and from coding as a hobby. The "tutoring" I received consisted of one half-baked, 30 minute lesson about the basics of HTML, and my "training period" consisted of watching some YouTube tutorials for close to two weeks, after which I was already being assigned tasks (that I was obviously not ready for).
Virtually all of my knowledge and experience was gained on-the-job, much of it through ad-hoc googling, and it was months before I actually went back and strengthened my knowledge on the fundamentals. And, for an even longer time, concepts like CORS, XSS and Virtual DOM remained unclear to me.

It's not like I'm at the top of the industry today (still working on it!) but I've definitely gained a lot of experience and knowledge as a web developer, and have created some awesome projects along the way. And you can too! don't let anybody deter you from it.

My bottom line is - don't let any random list of technical terms discredit your journey as a developer. Be proud of what you know, and be curious in what you don't.

And, perhaps most importantly, be a good person; see people, not their labels, and invest energy in helping them improve instead of discouraging them from doing so.

How are you using Styled Components?

Nitzan Hen — Sat, 27 Nov 2021 00:11:17 +0000

Hello!
Have you ever used style-components in a React project before? And, more generally, what are your thoughts of it?

I'm asking because we want to implement styled-components support for Agrippa, the React CLI for component generation! In fact, it's the second issue opened on our GitHub repository!

However, I unfortunately have never personally used styled-components in a production project, and while I did propose an implementation on the GitHub issue, it would definitely be better to hear an experienced input.

From what I've seen, different teams have used this tool in many different ways over the years.
Therefore, I'd love to hear your own experience with it, and how you're using it!
Even if you've used it in a small project or casually, speak up! the more experiences, the better - we could all learn something new as a result.

If you prefer, you're also more than welcome to join the discussion on the mentioned GitHub issue at Add support for styled components, and join the Agrippa community!

Thank you for your time!

(Cover image is from styled-components' docs, at https://styled-components.com/meta.png)

Agrippa 1.2 is out 🎉🎉

Nitzan Hen — Thu, 21 Oct 2021 08:42:10 +0000

Agrippa is growing steadily - it's been out for a little over two months, and already has a small community around it! 🎉🎉

If you're not using Agrippa yet, get started here. If you are using Agrippa, thanks for being part of the community! Let us know what you think about it, here or elsewhere.

Either way, these are the changes introduced in v1.2.0:

In general, the two main changes brought about in v1.2.0 are more options, this time with a focus on supporting different structural conventions that exist among React developers.

Most notably, you can now:

export a component as a default export (instead of a named export)
declare a component as a function() declaration (instead of as a const with an arrow function)
create memo() components.

These changes came as part of a larger reform in component generation. Generation logic was remade from the ground up - instead of a large, unwieldy template, we now have proper composition patterns and a ComponentComposer; internal terminology aside, this reform makes it much easier to scale, maintain and test the generation logic.

Following this reform, we have begun the process of writing standardized tests - testing for some of the core code already exists, and the rest will be covered in the soon future.

In parallel, we got some bonus enhancements - the API docs were rewritten and are now both comprehensive and easy to read, and Agrippa will also now search for a new version when run, so that you'll always be informed when a new version is available.

You can also find this information at the release page.

That's pretty much it! We already have some ideas for v1.3.0 - we're currently looking into adding support for styled-components, React native Stylesheets and Mui 5 styling, writing more tests and more.

Join the community! If you haven't, try Agrippa out, and if you find a bug in Agrippa or want to suggest a new feature, please reach out here or on GitHub.

Thanks for your time, have a great day!

Agrippa v1.1.0 introduces base directories and post commands

Nitzan Hen — Tue, 07 Sep 2021 16:06:34 +0000

About a month ago, the first production version of Agrippa was published, and I announced it in my first post on dev.to, Meet Agrippa, the React CLI for component generation. I was honored at the amount of positive feedback for the project (thank you all!!), and had immediately started working on improving the tool further.

v1.1.0

A few days ago, v1.1.0 of Agrippa was officially released! 🎉

The new version introduces two important new features for the React CLI:

Base component directory: projects can now specify a base directory, under which all components be generated! this makes Agrippa much more convenient to use in real projects, and can prevent developers from accidentally generating components in the wrong places. Read more about the base directory in the wiki page, using baseDir and dest.
Post command: users can now also specify a command to be run after generating a component, with the ability to inject into it dynamic paths (e.g. the component's path). For example, users use the post command to open new components in their favorite IDE automatically after generating them! For common recipes and more info, refer to the Post Command cookbook 🍲.

v1.1.0 also improves logging of info, debug information (with --debug) and errors.
Additionally, dependency versions were bumped (though this should have no impact on usage).

To update, call npm i -g agrippa (or, to use the new version directly, call npx agrippa [...]).

Also, we have a wiki now!

What's next?

Agrippa is still growing; I have some ideas in mind about how to improve Agrippa further, including more options and features, more standardized testing, more docs, etc.

That being said, Agrippa is meant to be useful to many React developers in many environments, including you! therefore, if you use Agrippa, and have found a bug or want to suggest an improvement, please open up an issue on GitHub!

One of the features currently in the works is support for styled-components. I, personally, am not too familiar with styled-components, so if you're using it, any suggestion or input about what can be useful for you is most appreciated! to join the discussion, see Add support for styled components on GitHub.

Also, we're considering opening a Twitter account for Agrippa, so be on the lookup for that!

Finally, if you like Agrippa, please spread around its word!

Meet Agrippa, the React CLI for component generation

Nitzan Hen — Tue, 10 Aug 2021 21:06:40 +0000

Finally, after over two years of writing the boilerplate of React components by hand, I'd decided to make snippets for them. However, I find myself working in quite a number of different environments (Typescript or JavaScript, different styling solutions, etc.), and it quickly became apparent that to accommodate for each and every reasonable combination, I'd be writing at least as much boilerplate as I'd sought to avoid.

To this end (as well as the desire to do something cool), I wrote a small CLI - Agrippa.

As the documentation reads,

"[Agrippa's] purpose is to assist React developers in creating components without the boilerplate. It can easily generate templates for React components of different compositions (styling solutions, prop validations, etc.) and in different environments."

Agrippa's leading features are:
🚀 Ease of use in both new and existing projects.
🐙 Flexibility - agrippa strives to be useful in many different circumstances.
🧠 Smart defaults - agrippa can detect and set defaults based on your environment's configuration, with no extra steps.
⚙️ Configurability - by using a plain old JSON file.

Usage

To get started with Agrippa, install it using npm i -g agrippa (or yarn global add agrippa).
Once installed, components can be generated using agrippa gen <name> [options]!

Some of the options supported by agrippa gen are:

--styling: which styling solution to use (e.g. CSS, SCSS, JSS, Material-UI).
--props: which prop validation/definition solution to use (e.g. Typescript interfaces, prop-types, JSDoc comments).
--children: whether the components is meant to have children or not.

Also, Agrippa automatically detects and sets other, important defaults for you, such as whether to use Typescript or Javascript, and whether to import React or not.

An exhaustive list of options and defaults, as well as more information, can be found in the GitHub repo or the npm page.

Community

My ambition is that Agrippa would become a tool that makes the lives of React developers easier, but perhaps more importantly one that they enjoy using. The tool's ease-of-use at the practical level is one aspect of that, but just as important is the cultivation of an active, positive community around it that developers feel welcome in.

Therefore, I invite you - yes, you - to become part of Agrippa's community. Your thoughts, suggestions and collaboration are most welcome.

Links: GitHub, npm.