auto-animate icon indicating copy to clipboard operation
auto-animate copied to clipboard

add standalone directive for new angular

Open createdbyjurand opened this issue 2 years ago • 7 comments

I had to create a standalone directive for new Angular to use it with standalone components. It would be nice to have it build in.

  • @formkit/auto-animate/angular
  • @formkit/auto-animate/angular-standalone
@Directive({
  selector: '[auto-animate]',
  standalone: true,
})

I am happy to contribute and create a pull-request just to make my mark on the project :) love it :) Or just do it yourself, I don't mind :) That is not that much work.

createdbyjurand avatar Jun 18 '23 12:06 createdbyjurand

#72 covers a discussion on this. The current project setup can not easily support ng-packagr for building a publishable Angular library since the Angular CLI is a required tool here.

ajitzero avatar Jun 18 '23 16:06 ajitzero

I noticed that Angular support is no longer available. Perhaps we should consider updating the landing page to reflect this change and provide clarity.

AsimNet avatar Jun 18 '23 17:06 AsimNet

The directive is fairly simple; you can copy and maintain your version for most projects.

I have made my library just for Angular because ~I plan to support~ I am supporting global options with an InjectionToken in the provider list.

ajitzero avatar Jun 18 '23 17:06 ajitzero

I’m happy to ship off angular support to another package like yours @ajitzero! I really don’t have enough experience with angular to have any recommendations for how to consolidate it here. That said, it seems totally wild that there isn’t a way to have a build system pack angular support into the /angular imports directory.

How many standards does Angular have to break for that to be the case 😂?

justin-schroeder avatar Jun 19 '23 14:06 justin-schroeder

Yeah, it's unfortunate but necessary in "Angular-land" because Angular code must be compiled and exported into a specific format for usage as a library (not talking about transpilation). They're not plain exported Js/Ts classes/functions. This is my understanding of the root problem.

I only know a little about this, and I leave all of the build system stuff on Nx (or Lerna or whatever works for you) for my own libraries. It allows me to target different frameworks as needed. Maintaining something for a single framework is hard enough, and here we're trying to do so for so many.

In the long term, this repo can benefit from migrating the project structure to Nx, but that's such a significant, non-trivial change; I figured we're better off with a spin-off library dedicated to Angular.

ajitzero avatar Jun 19 '23 14:06 ajitzero

I have no plans or desire to migrate this to NX or Lerna — there’s nothing inherent in those systems that is needed here. Even if we went multi-package I would still just use small discrete custom build tooling — I greatly prefer to own the build process as we do on formkit/formkit..

I’ll need to look into what angular actually needs here, but I feel quite confident we can build a subpath with everything it needs.

justin-schroeder avatar Jun 19 '23 14:06 justin-schroeder

In that case, please look at ng-packagr, the primary dependency for building these libraries.

Additional notes (from me making the wrapper library):

  • Peer dependencies:
    "peerDependencies": {
      "@angular/common": "^16.0.0", // missing in this repo, can be v14 and above
      "@angular/core": "^16.0.0",
      "@formkit/auto-animate": "^0.7.0"
    }
    
  • Need to be exported as a module.

ajitzero avatar Jun 19 '23 14:06 ajitzero