You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The background on this is in Covalent v4 many components were removed that had Angular Components equivalents. It has also been stated that going forward, Covalent will eventually remove any components equivalent to what Angular Material implements in the future. For existing projects that are in some cases deeply dependent on Covalent this causes the need for a major refactoring of their code base to accommodate these changes, as well as extensive testing to follow.
To prevent major breakages of existing dependent projects, a possible solution would be to implement adapter structures around the structures to be removed. If the plan is to migrate to Angular provided code then provide an adapter code structure in place of the old code structure (component, service, class, function) that uses the new Angular code instead.
The way I’m envisioning this for Covalent is under libs folder have a library called “angular-legacy” with adapters with the same api’s as the old code structures. These would be implemented similar to Covalent “angular-dynamic-forms” - “dynamic-elements” are, which would be a mapping of api properties from what old covalent code structures provided, to the new Angular code structure functionality.
The purpose of this is not a perfect adapter for the new Angular Material components, but rather a way to prevent projects depending on Covalent from having to make major refactoring's of their existing applications, so they can continue to keep their Angular and other dependencies up to date. You could also mention on your website that Covalent does not recommend using the “angular-legacy” components for new development, and to use Angular Material equivalents instead.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The background on this is in Covalent v4 many components were removed that had Angular Components equivalents. It has also been stated that going forward, Covalent will eventually remove any components equivalent to what Angular Material implements in the future. For existing projects that are in some cases deeply dependent on Covalent this causes the need for a major refactoring of their code base to accommodate these changes, as well as extensive testing to follow.
To prevent major breakages of existing dependent projects, a possible solution would be to implement adapter structures around the structures to be removed. If the plan is to migrate to Angular provided code then provide an adapter code structure in place of the old code structure (component, service, class, function) that uses the new Angular code instead.
https://refactoring.guru/design-patterns/adapter
The way I’m envisioning this for Covalent is under libs folder have a library called “angular-legacy” with adapters with the same api’s as the old code structures. These would be implemented similar to Covalent “angular-dynamic-forms” - “dynamic-elements” are, which would be a mapping of api properties from what old covalent code structures provided, to the new Angular code structure functionality.
https://github.com/Teradata/covalent/tree/main/libs/angular-dynamic-forms/src/lib/dynamic-elements
The purpose of this is not a perfect adapter for the new Angular Material components, but rather a way to prevent projects depending on Covalent from having to make major refactoring's of their existing applications, so they can continue to keep their Angular and other dependencies up to date. You could also mention on your website that Covalent does not recommend using the “angular-legacy” components for new development, and to use Angular Material equivalents instead.
Beta Was this translation helpful? Give feedback.
All reactions