I am a refined gentleman. And like most gentlemen, I prefer to use Angular as the front-end for my decentralized applications. I know you say that you’re using the Internet Computer, but are you really using the Internet Computer?
So Yeah- I am using Angular for my projects, and am sharing code so we don’t reinvent stuff, ya know? This is a play-and-play solution for anyone wanting to try out Angular with Motoko. After ‘npm install’, run ‘npm run deploy:local’ and it at least comes up for me. Easy to deploy on IC, just fill in ‘canister_ids.json’ with- you know. The ‘greet’ function returns in the console as a zone-aware promise. It is a 0.0.1 after all. I am adding state management for II. It is either going to be NGRX or Signals. Signals is in beta, so leaning more towards NGRX.
Sir, I am also a gentleman respecting the league of angular and motoko. Allow me to add my 5 pence. Feel free to use standalone components and signals. This works great. RxAngular is also a godsend for performance and has a good state manager. Don’t forget to add .dfx to .gitignore
I say good sir, you caught me with my .dfx hanging out! Don’t worry, it has been .gitignore’d, before further embarssement is to be caused; especially with a file as large as my .dfx!
Thanks for the RxAngular mention! I am rifling through its documentation section even as we speak!
Yes: I am going to be updating this to reflect the latest versions. I will have something out soon.
With Angular not receiving much love in Web3, my plan is to keep up two repos to make it easy for anyone wanting to try it for their dapps. The goal is to make it as plug-and-play as possible.
Angular ‘X’ and Motoko. Base Angular and Motoko. Basic Front Page with Internet Identity integrated as a service.
Easy Am I (Enterprise Angular Motoko Ionic). A more heavy-duty repo. With Landing Page, II login, Accounts and a Dashboard.
Currently I work on my next course with Angular 17 as frontend and Motoko as backend canister to help developers in their transition from Web2 to a Web 3 developer.
Good sirs, I shall partake this league of refined gentlemen appreciating the wonders of Angular 17.
I dare say these custom webpack configurations are not so refined. I would be honored to share with you an Angular CLI plugin that can banish this ugliness to the node_modules black hole.
No promise is complete without anticipation, I would share this treasure later today, once I arrange my rabbits appropriately and would invite your honorable feedback.
Yes! I’ve had some bugs I’m trying to sort out, specifically with the authentication side. So in general I would say it works, but is not production-ready yet. On the authentication side, you can log in and log out but you may encounter some weird things related to idling and expiration.
The instructions in the readme are for contributing to the project. I should add MacOS support for the system setup scripts, but you can also just follow those steps manually and translate them to the MacOS equivalent if you want to contribute to the repo, but basically you just need to install fnm (or a specific version of NodeJS), pnpm, commitizen and dfx.
the main branch is without a custom-webpack-configuration and uses esbuild. It uses an prebuild script to rewrite the environment/environment.ts file for three different deployment methods (local, playground, ic)
the second branch, called angular-ic-custom-webpack, uses a custom-webpack-configuration to read the .env file and a proxy config for all /api calls.
Both examples use their own createActor function implemented in an Angular service to not use the index.js file in src/declarations/backend/. Because this file is rewritten every time you generate new declarations (dfx generate backend).