# 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


## 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?