---
# System prepended metadata

title: "WiM.\U0001F41D Frontend -- Technical Debt Day"

---

# WiM.🐝 Frontend -- Technical Debt Day
https://zoom.us/j/7593541439 [Alohomora](https://www.youtube.com/watch?v=0CEOotN4Px4)

|Start Time|What?    |Whom?|
|----------|---------|-----|
|8:30|General  |Joscha|
|8:40|What is the Purpose of today? What are our expectations?|Dganit/Konstantin, everyone|
|8:50|What are **S**ingle **P**age **A**pplications? Main Concepts and Introduction| Mir|
|9:30|**Individual Brainstorming** (_shortly describe your wishes in a fair and descriptivly short manner as text_)|everyone individually |
|10:00|**Joint Clustering** (_Everyone names their findings **without** discussions; then identifies other peoples findings and merge them to clusters; try to reduce the number of points to be discussed later on_)|everyone together|
|10:30|Time Capped Discussions on every Cluster|everyone|
|12:30|How to proceed short and long term? Do we need a single or regular modus operandi meeting?|everyone|
|12:45|Lunch?? Hopefully.||
|Afternoon|Start Fixing Stuff|everyone who feel the can contribute code wise|

## Ideas:
+ Mir: Primer on SPAs / architecture
+ Hamid: Have a roadmap

---

## Round 1 (9:00-10:00): Brainstorming and Collecting **High Level** Issues
Add your findings in an understandable, short and descriptive way.
|What|No no 😿|Yes yes 😺|
|----|--------|-----------|
|Stay on point.|"Last year in december there was a comment..."|"We had the issue, that"|
|Stay factual.|"This is because you refuse to ..."|"I read in the code, that..."|
|Phrase in positive terms.| "X is bad."|"Y is good, because..."|
||"A did ... wrong."|"We should..."|
|Stay high level|"line 75 is wrong"|"Generally we should"|



### Konstantin
+ **Names**
  + **Names** should indicate the character of the values they carry, because this makes the code readable.
  + **Similar things** should have **similar names**, because this avoids guessing and surprises.
  + We should obey **naming conventions** because they are conventions for a good reason.
  + We should **avoid ambiguos names** and rather break and refactor existing code than stick with ambiguos names because now is better than never.
+ **Types**
  + **Typing** should specify the kind of value that variables carry, because this adds compile time safety and empowers our IDE.
  + Especially Shared/public variables should have the **obvious type**, we'd expect them to have, because this reduces overhead.
+ We should use more **enums** because this adds compile time safety and empowers our IDE.
+ Code should be **modular**, because this avoids fixing the same bug 5 times.
+ If the backend provides use with **schemes** (aka interfaces), we should use them because it allows for fast iterations.
  + example @Franzi: [`ProcessHeadInfo`](https://github.com/Hochfrequenz/wim-bee-frontend/blob/89418e4d9b4c1c36059de8056b61ff5fd20d862a/src/services/ProcessServices.ts#L43)
+ **Comments**
  + Comments should describe what we could _not_ guess from the name or reading 1 line of code.
  + Methods should have **docstrings** because this enables us to understand their purpose without debugging them.
+ **Requests** should describe what they expect to retrieve either by providing a scheme or at least a prose (readable, human readable text) description.
+ If using a **paramters + return value** is easily possible we should prefer this over instance variables.
+ At one point, **automated tests** would be great.

### Mir
+ **its better to call "get" api ones in the page**

+ **whats is SPA and Why are we using vujs? "what benefit vuejs brings"**
 
+ **never repeat yourself**
  + in programming one of the basic fact is DO NOT REPEAT YOURSELF, this will make the debugging much easier and code will be more maintainable and more
+ **comments**
  + we shouldnt have any code that is commented out in the project, if we need it in other branch we can move them in other branch but not commenting them.
  +    we should remove console.log() in the code before pushing our code for review, "it happens a lot to me too but when someone tell me there is a console i will remove it"
+ **use es6 and moder javascript**
    + even the code that we coppy pasting is written by joscha and its a good code it might written 4-3 years ago when some new methods wasnt exist, so please when we use old code to coppy try to change it to new syntax 


+ **master and develop should always work**
    + master branch and develop branch should never have error or break that means never push code that can break or bring the app down into develop or master.

### Hamid

+ **Axios calls**
    + All axios calls should go to the specific .ts files as a service.
+ **CSS**
    + findout the common css styles and inset it to a single .css file and for each .vue file we can have specific styles in < style > section.
    + solid solution for selecting CSS style approach in whole project (Bootstrap, Vue Styles, Icons etc.)
+ **Object-Based ts files**
    + It would be better if each seprated .ts file were related to own specific Object.
    + Following the OOP roles as much as possible.
+ **Having General view**
    + we should findout common madules to use that in other VueJs projects orr borrow some modules from other projects.
+ **Before creating PR**
    +  Removing all Logs
    +  Removing all unnecessary commented codes
    +  Checking naming conventions
    +  prettify codes
    +  testing and running it locally and making sure everything works fine
    +  write some descriptions on PR (+ screenshot of new changes will be helpful ;) )
+ **During PR process**
    +  Answering all review comments
    +  All conversations should be resolved before Merge (Ideally by reviewer)
    +  requesting more than 2 persons for review
+  **during coding tips**
    +  big static JSON data should goes to own .json file 
    +  allways pay attention to title of each page
    +  allways pay attention to tooltips and alternative text of each image or link

### Robert

+ **index.ts**
    + we have three files which are call index.ts
    + what's the sense of the index.ts and why we have three of them?
+ **css**
    + should it be better to create a base css-file instead of style elements in the .vue files in the `<script>` element?


### Kevin
* what is the purpose of a public folder?
* is it possible to replace our logos with a **vector format** like svg?
* is there a **naming** scheme?
    * _konstantin: yes=> [Javascript Naming Conventions](https://www.robinwieruch.de/javascript-naming-conventions) hamid posted in the channel last week_
    * variable name:
    * function name:
    * class name:
    * methode name:
* spacing is 2 spaces
  * konstantin: _linter&prettier take care of that._
* are single name variables a thing in JS?
* what is the difference in the definition of an enumeration 

### Annika
* Descriptive **names** of files or is that common/necessary in front end?
* More **comments**, docstrings?
* Maximum **line length**
* Still unsure about the **structure** of the project (index.html, 3x index.ts, ...)
* Vue logos and pages leftovers from starting example?


### Franzi
+ **componentes vs views folder**
    + I would love for someone to explain to me what belongs in which of those  areas and why (i read something before but you know how it is...)

+ I would also be happy to learn more about how modularity can be properly achieved - sounds good to me but don't know how exactly that has to look like


### Joscha
+ use a proper **logging library** (!= exception library)
+ account for **multiple environments** early (different customers, different systems (dev/qa/prod))

---

## Round 2 (11:20-???): Clustering our Findings

copy paste agreed on: ✅
copy paste disputed: ❌
copy paste needs examples or clarification: 📌

### Structure

### Comments
+ Comments should describe what we could _not_ guess from the name or reading 1 line of code.✅
+ **Methods** should have **docstrings** because this enables us to understand their purpose without debugging them.✅
  +_preferably something formalized_, joscha will check 📌
    + **Requests** should describe what they expect to retrieve either by providing a scheme or at least a prose (readable, human readable text) description.
### Names

+ **Similar things** should have **similar names**. ✅ with examples
+ **variable names** should indicate the character of the values they carry.✅
    + iterable objects (lists, dictionaries, arrays, ...) should be plural ✅
+ We should obey **naming conventions**.✅
    + [Javascript Naming Conventions](https://www.robinwieruch.de/javascript-naming-conventions)
+ We should **avoid ambiguos names** and rather break and refactor existing code than stick with ambiguos names.
+ Avoid one letter variable names which goes over multiple lines ✅
    + it's okay for indexes and one liners and lambda functions
    + ToDo@Kevin add examples here 📌
    + `cars.filter(c=>c.colour==="RED")`
+ Descriptive names of **files** if it is possible to rename them ✅

### Interaction with User
+ Show user meaningfull error messages ✅
    + backend needs to return some id
    + if the user sees an error, it should be also visible for us
+ Error messages for user should be in German
+ from the backend will come English error messages

### Interaction with Backend
+ All axios calls should go to the specific `.ts` file as a service ✅ 
    + for each backend api there should be a own service `.ts` file
         + mydomain.de/foo => FooService => `fooservice.ts`
         + mydomain.de/bar => BarService => `barservice.ts`


### General Programming

+ Code should be modular and not repeat itself. ✅
+ If possible use a **vector format** like svg for images ✅
    + if possible use fonts with icons
    + in web applications you should also take an eye on the file size
+ **Typing** should specify the kind of value that variables carry ✅
    + `greeting: str = "Hello World"` (is this also JS correct?)
    + try to avoid `any`
+ Especially Shared/public variables should have the **obvious type**. ✅
    + Example: If you need a datetime, stick to the datetime type until you need it as string and convert it to string where it's needed
+ Maximum line length
    + 80 characters
    + set prettier config to this value 📌 => [`--print-width`](https://prettier.io/docs/en/options.html)
+ Having each seprated `.ts` file its own **specific Object**. ✅
+ Following the **OOP** roles as much as possible.📌 ToDo: hamids präsi
+ use a proper **logging library** (!= exception library)
    + raygun is 
+ account for **multiple environments** early (different customers, different systems (dev/qa/prod))
    + shifted to another session 📌 todo konstantin 
+ big static **JSON data** should goes to own `.json` file 
    + big = objects is bigger than half of the screen ;)
+ findout the common css styles and inset them to a single common .css file and for each .vue file can have specific styles in `<style>` section. ❌
+ solid solution for selecting **CSS** style approach in whole project (Bootstrap, Vue Styles, Icons etc.)
## Round 2b (processual, not actual progamming stuff)
_discuss if time left or postpone to another meeting or weekly_ :D 
+ **Before creating PR**
    +  Removing all Logs
    +  Removing all unnecessary commented codes
    +  Checking naming conventions
    +  prettify codes
    +  testing and running it locally and making sure everything works fine
    +  write some descriptions on PR (+ screenshot of new changes will be helpful ;) )
+ **During PR process**
    +  Answering all review comments
    +  All conversations should be resolved before Merge (Ideally by reviewer)
    +  requesting more than 2 persons for review
+ we should findout common madules to use that in other VueJs projects orr borrow some modules from other projects.
+  allways pay attention to **title of each page**
+  allways pay attention to **tooltips** and alternative text of each image or link
+ Remove files that are not used or leftover from starting example bevor merging into master/develop branch for better overview
---

## Round 3:
How do we proceed?

## Single Page Application (SPA)

* Router
    * normally click on page will reload whole page
    * in a SPA it will **not** reload the whole page, but replace components (that's the difference between `:href` and `href`)
    * gives you the structure of your project 
* Life cycle methods

Life cycle diagram in vue.js

![life cycle diagram in vue.js](https://vuejs.org/images/lifecycle.png =500x)


## Conclusions

### Don't repeat yourself

### What is a component?
+ A component is useless/dumb on its own and only makes sense in an application context. 
### What is a page?
