Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming component vs data #18

Open
petervdn opened this issue Jun 23, 2020 · 3 comments
Open

Naming component vs data #18

petervdn opened this issue Jun 23, 2020 · 3 comments

Comments

@petervdn
Copy link

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
Copy link
Member

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

@ThijsTyZ
Copy link

ThijsTyZ commented Jun 23, 2020

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
Copy link

psimk commented Dec 30, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants