search
search copied to clipboard
creativecommons
[Feature] Refactor engine card html code into a reusable component
Problem
The engine cards are currently displayed by duplicating an existing html code. The search engines are often added/removed and so to prevent situations such as:
- the engines are added in the wrong positions on the page (such as #109)
- some errors while copying
- updating one card means updating each card manually
Description
An HTML component of the engine card can be created using JS and then called with its respective values.
This will reduce potential for errors, and make it easier to understand the layout when adding | removing | rearranging the search engines.
Bonus: It improves readability of that section and reduces the number of lines of code
Alternatives
Implementation
- [x] I would be interested in implementing this feature.
@Rubadel I already indicated to work on this if approved
If you have had a successful PR merge it's advisable to allows new applicants to try and contribute while you assist:)
Sorry, I do not understand, could you clarify more ?
I was talking to @JennySimen ....
Thanks for this contribution, I've been thinking on it and here's where I've landed:
The overall direction the CC Search Portal needs to be going is towards simplicity, longevity, and stability. I don't think introducing Javascript based components at this stage is necessarily going to accomplish that. As simple as this Search Portal is, waiting on JS to render out HTML isn't the best use-case for performance on the f/e for the user. In that way, it's a case of improving developer experience while sacrificing long-term stability of the project, and possibly impacting the user/visitor's experience in a negative way. That's not a trade-off I'm entirely sold on.
I agree that there are issues when adding new engines, and the layout shifting, but that has more to do with the HTML not being semantic, having styling classes, and the CSS not utilizing newer layout methodologies like Flexbox or CSS Grid, instead of a Bootstrap-esque grid system it has now.
It might make more sense to shift this Issue in the direction of updating how the layout of the engines grid is done in the first place; as in: making the HTML semantic, removing style-based classes for layout, and introducing more modern layout methods (likely flexbox) for targeting that area via CSS. If that was done on the engines grid alone it would make adding new engines less buggy, while keeping the code stable HTML and CSS, rather than adding another layer of abstraction with JS rendered components.
@possumbilities I think it makes more sense to move in that direction and use just HTML and CSS.
So, I will add some suggestions on how to continue in that direction.
@possumbilities CSS Grid is very flexible and responsive. It makes it easy to create two-dimensional layouts.It will also be easy to use and is supported by most web browsers. The CSS grid will improve the mark-up and provide more flexibility. Seeing that there are 10 engines currently, we will put them in a div with a general class name. Each engine will be in a div having the same class name.
For the css, we will align the items by styling the container name where the engines are found using something like this:
display: grid;
grid-template-columns: auto auto auto;
We will use gaps as well to have uniform spacing horizontally and vertically.
When a new engine is added at the end of the main div, the developer only has to give it the child css class and it will automatically align with and fit the main grid.
Resolved in new site merge: https://github.com/creativecommons/search/pull/206