search

mediamonks / frontend-coding-standards

Media.Monks - Frontend Coding Standards
60 stars 23 forks source link

Naming component vs data #18

Open petervdn opened 4 years ago

petervdn commented 4 years ago

https://github.com/mediamonks/frontend-coding-standards/tree/feature/readme#naming

Maybe add a section on how to name data vs the visual component that represents it? 

Message
MessageModel
MessageData
MessageView
ThaNarie commented 4 years ago

Can you add a bit more context? This can be vastly different depending on the framework or state library that is used.

ThijsTyZ commented 4 years ago

This is very much depended on the project, the domain model, the external API's and frameworks and/or libraries that are used.

But in general:

You should avoid names with only a single word, like Message. This does not provide enough information and can even cause conflicts. (In Muban there is currently a eslint issue for components with a single word as name because the class is writting in PascalCase, while the template file is written in kabab-case.)

Data (like MessageData) is generally used for objects that holds information about something. These objects are usually just interfaces or types. They usually don't have (much) logic.

Model (like MessageModel) is generally used as a wrapper around the data and adds more logic, like filtering, searching, transforming, etc. All methods in the model are (usually) synchronous.

Service (like MessageService) is pretty similar to the model, but with asynchronous logic.

View (like MessageView) is the visual implementation. It usually gets a data, model and/or service.

But I don't think we should put this into rules, because this is very much dependent on the context.

Depending on the framework or library there are also terms like, Component, Module, API, etc. and some might have a different meaning.

I think it's more important to be consistent within a project. So a Component, Model, Data etc. means the same thing through out the whole project. For big projects it therefor makes sense to create a dictionary (as a .md file in the root of the project) to explain the used terminology within the project)

psimk commented 3 years ago

I think we should revisit this issue, in particular these 2 topics in relation to variable naming:

  1. Library specific naming guidelines; e.g. for styled-components are we prefixing each styled component with Styled ? and are we also making sure that each of the styled components names consists of it's file name? e.g. Tab.styles.tsx -> StyledTabContainer, StyledTab, StyledTabWrapper.
  2. With scripting there's a lot of usage of store and state in variable names, under which circumstances we should use either one?