<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Maryam</title>
    <description>The latest articles on DEV Community by Maryam (@maryamtavana).</description>
    <link>https://dev.to/maryamtavana</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1454295%2F0614c2fb-3e89-4632-84d3-e13b8003c62c.jpg</url>
      <title>DEV Community: Maryam</title>
      <link>https://dev.to/maryamtavana</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/maryamtavana"/>
    <language>en</language>
    <item>
      <title>How to name the components in VUE-JS</title>
      <dc:creator>Maryam</dc:creator>
      <pubDate>Wed, 08 May 2024 14:13:56 +0000</pubDate>
      <link>https://dev.to/maryamtavana/how-to-name-the-components-in-vue-js-1gbb</link>
      <guid>https://dev.to/maryamtavana/how-to-name-the-components-in-vue-js-1gbb</guid>
      <description>&lt;p&gt;&lt;em&gt;When coding, I always faced a fundamental issue on how to name classes and components to maintain a clean structure and follow specific principles in vue-js. Sometimes, I used kebab-case for component names, class names, variables, and everything else. Occasionally, I applied camel-case for all, and at times, I defined each in a different way. However, I realized this approach led to a disorganized and unreadable project structure.&lt;br&gt;
Therefore, I decided to conduct research on general naming conventions to define my project structure according to specific principles and move forward.&lt;br&gt;
As a result, it turned out like this.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;1.Multi-word component names&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Component names should be multi-word , except for root App components, and built-in components provided by Vue, such as  or .&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;         ❌                         ✅

        Todo                     todo-item
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;strong&gt;2.Single-file component filename casing&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Filenames of single-file components should either be always PascalCase or always kebab-case.&lt;br&gt;
PascalCase works best with autocompletion in code editors, as it’s consistent with how we reference components in JS(X) and templates, wherever possible. However, mixed case filenames can sometimes create issues on case-insensitive file systems, which is why kebab-case is also perfectly acceptable.&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;         ❌                         ✅            

   mycomponent.vue             MyComponent.vue
   myComponent.vue             my-component.vue
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;strong&gt;3.Base component names&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Base components that apply app-specific styling and conventions should all begin with a specific prefix, such as Base, App, or V.&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;         ❌                       ✅

    MyButton.vue               BaseButton.vue
    VueTable.vue               AppTable.vue
    Icon.vue                   VIcon.vue
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;strong&gt;4.Single-instance component names&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Components that should only ever have a single active instance should begin with the The prefix, to denote that there can be only one.&lt;br&gt;
This does not mean the component is only used in a single page, but it will only be used once per page. These components never accept any props, since they are specific to your app, not their context within your app. If you find the need to add props, it’s a good indication that this is actually a reusable component that is only used once per page for now.&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;         ❌                       ✅

    Heading.vue              TheHeading.vue
    MySidebar.vue            TheSidebar.vue
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;strong&gt;5.Tightly coupled component names&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Child components that are tightly coupled with their parent should include the parent component name as a prefix.&lt;br&gt;
If a component only makes sense in the context of a single parent component, that relationship should be evident in its name. Since editors typically organize files alphabetically, this also keeps these related files next to each other.&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;         ❌                        ✅

    TodoList.vue              TodoList.vue
    TodoItem.vue              TodoListItem.vue
    TodoButton.vue            TodoListItemButton.vue
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;strong&gt;6.Order of words in component names&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Component names should start with the highest-level (often most general) words and end with descriptive modifying words.&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;         ❌                         ✅    

  ClearSearchButton.vue      SearchButtonClear.vue
  TermsCheckbox.vue          SettingsCheckboxTerms.vue
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;strong&gt;7.Full-word component names&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Component names should prefer full words over abbreviations.&lt;br&gt;
The autocompletion in editors make the cost of writing longer names very low, while the clarity they provide is invaluable. Uncommon abbreviations, in particular, should always be avoided.&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;          ❌                        ✅          

    SdSettings.vue         StudentDashboardSettings.vue
    UProfOpts.vue          UserProfileOptions.vue
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;strong&gt;8.Prop name casing&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Prop names should always use camelCase during declaration, but kebab-case in templates and JSX.&lt;br&gt;
We’re simply following the conventions of each language. Within JavaScript, camelCase is more natural. Within HTML, kebab-case is.&lt;/p&gt;

&lt;p&gt;&lt;code&gt;props: {&lt;br&gt;
'greeting-text': String ❌&lt;br&gt;
}&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;&lt;code&gt;props: {&lt;br&gt;
greetingText: String ✅&lt;br&gt;
}&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;&lt;code&gt;&amp;lt;WelcomeMessage greetingText="hi"/&amp;gt;&lt;/code&gt; ❌&lt;/p&gt;

&lt;p&gt;&lt;code&gt;&amp;lt;WelcomeMessage greeting-text="hi"/&amp;gt;&lt;/code&gt; ✅&lt;/p&gt;

&lt;p&gt;&lt;em&gt;&lt;strong&gt;How do you name Html classes?&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;1.Use lowercase and hyphens&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="MainHeader"&lt;/code&gt; ❌&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="main-header"&lt;/code&gt; ✅&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;2.Be descriptive and consistent&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="btn-style1”&lt;/code&gt; ❌&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="button-primary"&lt;/code&gt; ✅&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;3.Avoid using presentational or structural names&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="red"&lt;/code&gt; ❌&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="error"&lt;/code&gt; ✅&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;4.Follow the BEM methodology&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="card--title--large"&lt;/code&gt; ❌&lt;/p&gt;

&lt;p&gt;&lt;code&gt;class="card__title--large"&lt;/code&gt; ✅&lt;/p&gt;

&lt;p&gt;&lt;em&gt;I’ve decided to adopt these methods for my projects because they’ve made my project structure cleaner and my code more readable. I hope this article has been able to help you as well.&lt;br&gt;
Thanks for reading. I’m looking forward to your feedback.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Best wishes.❤️&lt;br&gt;
Maryam Tavana&lt;/strong&gt;&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
