Content
View differences
Updated by Aleix Suau over 5 years ago
Currently, autocompleters for the work packages look and in parts also behave differently throughout the application.
This requires users to learn how to autocomplete work packages in a couple of variants. Additionally, for some use cases, the provided information does not suffice to decide between two equally named work packages.
The goal of this work package is two-fold:
1. Let the behaviour of work package autocompleters be equal where appropriate while being able to afford some differences where necessary. For example, the results of the autocompleters might always look the same but there might be some additional options within one specific autocompleter e.g. the search.
2. Reduce, the amount of different code we have (number of components) for autocompleting work packages.
For now, we use the search autocompleter as a reference when it comes to displaying the results:
<figure class="image op-uc-figure" style="width:34.51%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/19808/content"></div></figure>
As we have a number of WP autocompleters throughout the application, the first task is to identify all the places that are currently sport one. Then, we can improve those autocompleters as seperate topics (read work packages) one by one.
Please note that there are other autocompleters within the application already (e.g. for users, versions, projects ...). While those are out of scope for now, we should keep in mind that they need improving as well.
**Development Notes**
1- As I mentioned in the comments, in current WP autocompleters implementations, we used different data source types like SearchResultItem and SearchOptionItem interfaces in global search autocompleter, WorkPackageResource in the autompleter used for selecting WP in boards, another interface named ValueOption used for time logging auto completer. The usage of different types was necessary based on the functionality of each autocompleter, for example for global search autocompleter we need two interfaces one for showing the WP data another for 3 first options(in this project, in all project,…).
2- Moreover, some of the autocompleters have an array as their data source like version autocompleter used in version board, while others have observable of an array.
3- Another important difference is the method for fetching data, for identical resource in this situation WP, we have different methods for getting data. For example in time logging autocompleter, based on selecting which tabs (recent, all), it fetches the data from a $link of the edit-field schema. Or in selecting a relation for WP, it uses another method like below to fetch the related WPs:
```Javascript
from(
this.workPackage.availableRelationCandidates.$link.$fetch({
query: query,
filters: JSON.stringify(this.additionalFilters),
type: this.filterCandidatesFor || this.selectedRelationType
}) as Promise<WorkPackageCollectionResource>
)
```
However, in global search and while selecting a WP in boards, we are using APIV3 and fetch the data from the work\_packages.
4- We have three different autocompleters based on their appearance:
* global search that used for searching in different modes (in this project, in all projects) with its unique open and close functionality,
* autocompleters with tabs used in time logging that the user should select a WP from recent WPS or all WPs tabs,
* autocompleter with usual functionality and view that is used in boards for selecting a WP. We also show different WP information in each autocompleter.
These three kinds of autocompleter have different implementation for their views.
5- In global search auto completer, we handle several events that are not considered in none of others like pressing Enter or Escape buttons, focus and blur.
6- The styles used for global search autocompleter is unique for it and by setting classes it handles the mobile view also. Moreover, other autocompleters have their own sass file for their styles.
7- There are different reactions after selecting an option, for example in global search autocompleter after selecting a WP, it redirects to its full view page, however, by selecting a WP in a board column, it will be added to that column.
8- Moreover, in global search autocompleter not only we set an ng-Model for ng-select and set a function for change event, but also we set two functions for clicking on each options of it, while, other autoompleters don’t have a model binding and set only a method for change event of ng0select.
9- Another difference is handling close and open events, in most of autocompleters after opening, it only updates the position of the dropdown but in global search autocompleter it only set the property isOpen of ng-select to true. Moreover, in all autocompleters after closing, they emit an output. But in global search autocompleter, it sets the search term of ng-select.
10- Each ng-select in autocompleters has different options, they are not the same. ‘appendTo’ , ‘multiple’, ‘placeholder’, ‘accesskey’, ‘searchFn’ and …. are not the same for all of them.
Maybe there are more differences among them, as I just tested the application and went through the codes, i found them. At first, i decided to create a global component that can be used as an autocompleter that receives the resource type and has some other inputs for fetching data. Now, I am not completely sure that we can implement all of these different functionalities in just one component with various views.
**Main differences categories**
* **Data:**
* Fetch
* Interface
* Most recent used wp
* **Appearance**
* Information (Templates)
* Tabs
* Styles
* **Functionality**
* Open and close
* Tabs
* **Configurations** (@Inputs)
* Events handled (@Outputs)
* appendTo’ , ‘multiple’, ‘placeholder’, ‘accesskey’, ‘searchFn’
**Alternatives to explore:**
* Find a way to change default ng-select templates so we don't have to write on every place we use it and we can avoid create a new component wrapping it.
*
This requires users to learn how to autocomplete work packages in a couple of variants. Additionally, for some use cases, the provided information does not suffice to decide between two equally named work packages.
The goal of this work package is two-fold:
1. Let the behaviour of work package autocompleters be equal where appropriate while being able to afford some differences where necessary. For example, the results of the autocompleters might always look the same but there might be some additional options within one specific autocompleter e.g. the search.
2. Reduce, the amount of different code we have (number of components) for autocompleting work packages.
For now, we use the search autocompleter as a reference when it comes to displaying the results:
<figure class="image op-uc-figure" style="width:34.51%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/19808/content"></div></figure>
As we have a number of WP autocompleters throughout the application, the first task is to identify all the places that are currently sport one. Then, we can improve those autocompleters as seperate topics (read work packages) one by one.
Please note that there are other autocompleters within the application already (e.g. for users, versions, projects ...). While those are out of scope for now, we should keep in mind that they need improving as well.
**Development Notes**
1- As I mentioned in the comments, in current WP autocompleters implementations, we used different data source types like SearchResultItem and SearchOptionItem interfaces in global search autocompleter, WorkPackageResource in the autompleter used for selecting WP in boards, another interface named ValueOption used for time logging auto completer. The usage of different types was necessary based on the functionality of each autocompleter, for example for global search autocompleter we need two interfaces one for showing the WP data another for 3 first options(in this project, in all project,…).
2- Moreover, some of the autocompleters have an array as their data source like version autocompleter used in version board, while others have observable of an array.
3- Another important difference is the method for fetching data, for identical resource in this situation WP, we have different methods for getting data. For example in time logging autocompleter, based on selecting which tabs (recent, all), it fetches the data from a $link of the edit-field schema. Or in selecting a relation for WP, it uses another method like below to fetch the related WPs:
```Javascript
from(
this.workPackage.availableRelationCandidates.$link.$fetch({
query: query,
filters: JSON.stringify(this.additionalFilters),
type: this.filterCandidatesFor || this.selectedRelationType
}) as Promise<WorkPackageCollectionResource>
)
```
However, in global search and while selecting a WP in boards, we are using APIV3 and fetch the data from the work\_packages.
4- We have three different autocompleters based on their appearance:
* global search that used for searching in different modes (in this project, in all projects) with its unique open and close functionality,
* autocompleters with tabs used in time logging that the user should select a WP from recent WPS or all WPs tabs,
* autocompleter with usual functionality and view that is used in boards for selecting a WP. We also show different WP information in each autocompleter.
These three kinds of autocompleter have different implementation for their views.
5- In global search auto completer, we handle several events that are not considered in none of others like pressing Enter or Escape buttons, focus and blur.
6- The styles used for global search autocompleter is unique for it and by setting classes it handles the mobile view also. Moreover, other autocompleters have their own sass file for their styles.
7- There are different reactions after selecting an option, for example in global search autocompleter after selecting a WP, it redirects to its full view page, however, by selecting a WP in a board column, it will be added to that column.
8- Moreover, in global search autocompleter not only we set an ng-Model for ng-select and set a function for change event, but also we set two functions for clicking on each options of it, while, other autoompleters don’t have a model binding and set only a method for change event of ng0select.
9- Another difference is handling close and open events, in most of autocompleters after opening, it only updates the position of the dropdown but in global search autocompleter it only set the property isOpen of ng-select to true. Moreover, in all autocompleters after closing, they emit an output. But in global search autocompleter, it sets the search term of ng-select.
10- Each ng-select in autocompleters has different options, they are not the same. ‘appendTo’ , ‘multiple’, ‘placeholder’, ‘accesskey’, ‘searchFn’ and …. are not the same for all of them.
Maybe there are more differences among them, as I just tested the application and went through the codes, i found them. At first, i decided to create a global component that can be used as an autocompleter that receives the resource type and has some other inputs for fetching data. Now, I am not completely sure that we can implement all of these different functionalities in just one component with various views.
**Main differences categories**
* **Data:**
* Fetch
* Interface
* Most recent used wp
* **Appearance**
* Information (Templates)
* Tabs
* Styles
* **Functionality**
* Open and close
* Tabs
* **Configurations** (@Inputs)
* Events handled (@Outputs)
* appendTo’ , ‘multiple’, ‘placeholder’, ‘accesskey’, ‘searchFn’
**Alternatives to explore:**
* Find a way to change default ng-select templates so we don't have to write on every place we use it and we can avoid create a new component wrapping it.
*