7 Matching Annotations
- Jan 2024
I thing you are doing a very subtle mistake which will become fatal in long-term. Your strategy to take small steps that cover as much functionality as possible is reasonable, but it is necessary to be careful, as it leads to a critical state when there is too much little stuff built up without proper structure to support it.
When the relations are implemented in the right way, they will simplify Gitlab, not make it more complex.
Another example are issue boards. They represent elegant use of a good infrastructure — it is all just a smart use of labels. It would be very complex feature without the use of labels.
Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.
- Jun 2021
- Dec 2020
I think the main difference between the two are the way API are served. Some smelte components need you to input big chunk of json as props, while i prefer keep props as primitive types and in the other hand give you different components tags to compose.
- comparing one's project/product with competition/alternatives
- nice API
- see content below
- API design
- better/superior solution/way to do something
- simple API
- better than the alternatives
- building blocks / primitives
- Oct 2020
On one hand Solid just provides a collection simple primitives like createState, createEffect, createMemo, etc.. These can be composed to create much more powerful behaviors.