DEV Community: Ayyash

When third party needs a forth party it becomes a crowd

Ayyash — Tue, 20 Oct 2026 10:00:00 +0000

Bootstrapping

To guarantee the order of events in a responsive web app, a bit of boilerplate is understandable. Angular has clear entrance points, and server injected tokens, that guarantee the app is not loaded before some specific events are done. In addition to explicit providers for almost everything that can be configured:

// the Angular bootstrapper

export const appConfig: ApplicationConfig = {

  providers: [
    // ...
    // this needs to resolve first
    provideAppInitializer(someFactory),
    providePlatformInitializer(),
    // just to name a few:
    provideServerRendering(),
    provideBrowserGlobalErrorListeners(),
    provideZonelessChangeDetection(),
    provideRouter(),
    provideHttpClient(),
    provideClientHydration(),
    provideEnvironmentInitializer(),
    // more custom providers
     { provide: ErrorHandler, useClass: OlErrorHandler },
     { provide: AnalyticsService, useClass: someSpecificService},
     { provide: 'stringValue', useValue: 'Medrid'}
  ]
};

bootstrapApplication(App, appConfig);

In Svelte, explicit file names guarantee lifecycle hooks on server, client and somewhere in the middle. In addition to the built in load function on the every .server.ts and .ts file.

// sveltekit provides:
// hook.server.ts
export const init: ServerInit // ...
export const handleFetch: HandleFetch // ...
export const handleHook: Handle // ...
export const handleError: HandleServerError // ...

// hook.client.ts
export const init: ClientInit // ...
export const handleError: HandleClientError // ...

// hook.ts
export const reroute: Reroute // ...
export const transport: Transport // ...

// +layout.server, +layout.ts and +page.server and +page.ts
export async function load({fetch, data}) { // ...

There is nothing in Svelte that guarantees order of events, so you find yourself often using tricks like loading on handle hooks, passing to specific load events down the branch of a route, using #await, setContext and await parent(), until it becomes tired.

You have what you need for basic functionality, but once you get into managing multiple balls and SSR, external configuration and your own internationalization solution, it quickly gets out of hand in Svelte but almost never does in Angular. Angular just won't let you. Which also comes with the price of heavier boilerplate. and more stubborn and opinionated environment.

Lifecycle hooks

Svelte has a set of App hooks for both client and server. In addition to two major Component hooks, a tick hook, and three Navigation hooks. (Documentation is not Svelte's strongest quality.)

Angular provides a good amount of Route hooks, Component hooks, a couple of buried Browser Render lifecycle hooks in addition to the events and interceptors that come along with the different out of the box solutions, like HttpClient interceptors.

The distinctive difference between Angular's OnInit and Svelte onMount was in observables. In Angular, once an observable is created, it can be fed and initialized on initialization

// OnInit in Angular
products$: Observable<Products[]>;

ngOnInit(): void {
    // start watching
    this.products$ = this.route.paramMap.pipe ...
}

In Svelte, you cannot use $state, or its siblings, nor store Readable inside onMount, unless you intend to subscribe once to a store.

let products = $state([]);
onMount(async() => {
    // state is never in onMount
    products = await someHttpService.GetProducts();
})

Another twist that is painful in Svelte, is hooking to initialization of content, projected in a parent content. Angular's AfterContentInit is a whole of unpredictable trouble in Svelte.

Generally speaking, Angular is much richer in available events and hooks, that does not make it easier to figure out the dark corners, but it gives you options to break free.

Nutshells

Few more points to rant and badger:

Documentation

No question that you start writing Svelte quite quickly because it's basically JavaScript. But once you start adding more specific features, the documentation of Angular is way ahead in the game. Many times did I go searching Svelte docs for something I knew I read before, just didn't remember where any more. The docs are found wanting.

Out of the box solutions

When I decided to jump into the SPA frameworks, I binge coded three options before I settled on Angular 2.0. One of the major drivers was that it had an out of the box solution for most of the issues covered in SPA. That matters because one third-party framework is one too many, I need to feel confident that source of truth is one, documentation is one, developers working on it are working together, they update together, and they backward-compatible their features together.

When Vite updated the other day, I felt trapped in Svelte. Did not feel the pain in Angular. And I still get bugs in my solution that matches routerLinkActive directive.

If you opt into having third party libraries (or better dubbed forth party libraries), you will have to continually watch and update those libraries, which in this day and age, isn't to be taken lightly.

Potentials

They both have potential for sure, Angular has much better support, which makes it too big to fail, it will end up like ASP.NET one day, not many use it, but those who do, swear by it. It won't die any time soon.

In terms of small-scale projects, with little or no SSR, single language, they both rank the same, but Svelte is simpler, I would say VueJs is the real contender in that department.

As the project gains complexity, state management, multilingual, hydration, extra features and complex routing, or when you have more developers working together, Angular is the way.

I always exclude React and its derivatives. I truly am not interested in that library that newbies pick because it's too easy. Common newbies. Do the hard work!

Side note about AI completion

I use Windsurf for code completion, Gemini, Copilot and paid Claude for coding. But I did notice that in Angular, the code completion is almost always correct, and the solution is almost much easier to understand. Svelte usually takes a while to teach the AI to pick up a pattern, and the solution is harder to explain. I don't know the real reason behind it, except that Angular is older, and the documentation is more thorough. And AI are just parrots, aren't they!

HTML sanitizing

I always used Angular's [innerHTML] to sanitize the HTML output, and I thought Svelte's @html does the same. Boy was I wrong. This brings me to the final odd conclusion:

Angular, somehow, makes you dumber, because you become lazy. But then again, where you around the times when we had to make buttons into table elements to create the illusion of rounded corners? We definitely wasted a lot of brain tokens on that!

When third party needs a forth party it becomes a crowd - Sekrab Garage

Angular vs Svelte. BootstrappingTo guarantee the order of events in a responsive web app, a bit of boilerplate is understandable. Angular has clear entrance points, and server injected tokens, that guarantee the app is .... Posted in Angular, Svelte

garage.sekrab.com

Server Side Rendering and support

Ayyash — Fri, 16 Oct 2026 10:22:56 +0000

There was much I wanted to say about SSR support but Angular 22 deprecated their CommonEngine and replaced it with AngularNodeAppEngine, I need to hit the drawing board again to replace my single-build-multilingual solution, that relies on CommonEngine and its ability to let in providers from the server world. Until then, I'm pissed off.

Following are quick notes about each framework, diving deeper is a different Tuesday.

Intent

Like everything in Angular, building for SSR is explicit. Need to include the right bootstrapping functions, and the correct server routes. In Svelte, I always wondered if I needed the server handle hook in all client-side app. I do. It's part of a custom Node server implementation, not necessarily SSR enabled.

// bootstrapping in Angular
const _app = (context: BootstrapContext) => bootstrapApplication(AppComponent, {
  providers: [
      // client providers
    ...clientProviders,
    // then the Angular providers for SSR
    provideServerRendering(withRoutes(serverRoutes)),
  ]}, context
);

export default _app;

Enabling in Svelte:

// root layout.ts
export const ssr = true;

// then you need to add a file hook.server.ts in src folder

Server side rendering and hydration

In both frameworks you can choose which routes to include in server side rendering, and which are not, in Angular it is a configuration file, and in Svelte it's a boolean you set at the root layout file. Which makes it quite all over the place.

// Angular: app.routes.server.ts
export const serverRoutes: ServerRoute[] = [
  {
    path: '**',
    renderMode: RenderMode.Server
  }
];

// SvelteKit any roote +layout.ts
export const ssr = false | true;

Svelte hydration is very particular, and if you use http requests, it must be through their load version of fetch. Angular is less particular but just as stubborn. Angular supports incremental hydration with a lot of ways to fine tune it out of the box. Svelte may disable ssr on a whole branch of a route tree, and that's just about it.

One downside of hydration expectations is when you need to manipulate the DOM. Angular however has its own DOCUMENT implementation using out of the box Node implementation (which, let's be frank, is probably a forth party under the hood) which allows directives to target the document anywhere it makes sense.

Request and Response

In addition to DOCUMENT token, Angular also provides REQUEST, REQUEST_CONTEXT, and RESPONSE_INIT. Svelte provides the shady getRequestEvent. I have personal beef with this function. To make the request event available, it must belong to the load tree. Axios for example, does not play nice with it.

To make the request available when you need it, you must burry it inside a .server file or inside lib/server file. If you want to implement a both server/browser behavior with access to that event, here is a good pattern:

// in hook.server
export const init: ServerInit = async () => {
  // pass server locals to all unsafe regions
  setLocals(() => getRequestEvent().locals);

}

// somewhere in utility file,
// expected function in client side is null
let _localsResolver: () => any = null;
export const setLocals = (fn: () => any) => {
  _localsResolver = fn;
};

// safe outside a request scope (browser, init, background work)
export const SiteLocals = (): any => {
  try {
    // that's where calling an ssr function, or a null client function
    return _localsResolver?.() || {};
  } catch {
    return {};
  }
};

// you use it in, say, an authorization header where server locals have the user
if (!browser){
    _token = SiteLocals().user?.accessToken;
}

I will keep Angular SSR deep dive for another Tuesday, because it's worth it.

Serving and building

Both frameworks serve SSR version during development time, ever since Angular adopted Vite. After building, running on a real server requires Node server setup, the server listener in Svelte is buried inside handler.js, and uses Polka, but exporting the handler, you can listen through a custom Node server . The Angular listener is part of the source code, and can be dropped, in favor of an external listener with the correct functions exported. A whole new Tuesday.

Injecting a configuration.json from the server in Svelte is not a straight forward operation. Here is a pattern to use:

// example custom Node server in Svelte

// this is how a path of global config is injected from /config/config.json
global.configPath = join(import.meta.dirname, 'config', 'config.json');

// hanlder is hoisted, better keep it late
const { handler } = await import('./build/handler.js');

const app = express();
// ... setup express as you like, with routes and special API handling

// then use handler
app.use(handler);

// then listen
app.listen(process.env.port, async function (err) {
    console.log('started to listen to port: ' + process.env.port);
    if (err) {
      console.log(err);
      return;
    }
});

Then in the source code of Svelte:


// server.hook.ts
export const init: ServerInit = async () => {
 // to read config file during dev time from /static, and keep it external on run time, the configPath is now dynamically read:
const configFile = join((<any>global).staticRoot || join(process.cwd(), 'static'), 'config.json');

// then the configFile can be ready normally as a Node file. I found this quite messy.
const raw = await readFile(configPath, 'utf-8');
// ...
// this is the configuration now ready to be setup locally and used
ServerConfig.Config = JSON.parse(raw);

In Angular however, because we have the App initializer that waits for any fetch operation to end, it is safe to simply fetch it. We can also provide it in the runner of the custom Node server. But here is an example of the configuration factory

// in main.ts
bootstrapApplication(AppComponent, {providers: [
    // ...
    provideAppInitializer(configFactory),
]});

// the factory looks like this
const configFactory =  () => {
  const config = inject(ConfigService);
  return config.loadAppConfig(); // this fetches the file
};

In the older (deprecated) version of ngExpressEngine, the ConfigService can optionally define a token that is provided on the server

// config.service

// string token provided by express routes (CommonEngine), inject() typing does not accept strings
const LOCAL_CONFIG = 'localConfig' as ProviderToken<IConfig>;

@Injectable({
  providedIn: 'root'
})
export class ConfigService {
  private http = inject(HttpClient);
  protected localConfig = inject(LOCAL_CONFIG, { optional: true });
  loadAppConfig(): Observable<boolean> {
      // this will be awaited until it resolves, so you can read the localConfig token on server, or you can simply fetch once, and cache forever
    return this.http.get(this._getUrl).pipe(
        // ... map, catch ... return observable whenever ready
    );
  }
}

This has already been covered in details previously in Utilizing Angular Tokens. But it has all been deprecated and replaced. The http fetch thought is still solid.

Now here is another trick to force Svelte to serve a certain file, from other than the static folder, during development time. Utilizing Vite plugins:


// in vite.config.ts
export default defineConfig((env) => {
  return {
    plugins: [
      {
        // quick middleware for dev environment during client fetch, to serve host/config/config.dev.json for /config.json
        name: 'config-json-proxy',
        configureServer(server) {
          server.middlewares.use('/config.json', (_req, res) => {
            // file location on disk
            const json = readFileSync('./host/config/config.dev.json', 'utf8');
            res.setHeader('Content-Type', 'application/json');
            res.end(json);
          });
        },
      },
     sveltekit(),
     // ...
     };

}) satisfies UserConfigFn;

Here is the same trick in Angular, this means any call in client side on /localdata/config.json, will fetch the physical file sitting in configs folder. This also means on build time, Angular will copy the file and carry it forward to host/localdata

// angular.json
{
    // projects.projectname.architect.build.options.assets
    assets: [
      {
        "glob": "*",
        "input": "configs",
        "output": "/localdata"
       },
    ]

}

API server support

Both frameworks have excellent support for API points, which is something I never use, because the music you face in real life is: API is a foreign server, written by a strictly-server technology assumed better than Node. Angular uses explicit routing, and Svelte uses file-system base routing. Which is again, a downside.

Vite

Both use vite under the hood, Svelte provides one configuration file to serve and build, and it exposes vite config to developer.

// vite.config.ts
export default defineConfig((env) => {
  return {
    plugins: [sveltekit()],
    preprocess: [vitePreprocess()],
      kit: {
       // ...
       }
    // ...
  }
}

Angular CLI wraps the vite under the hood, and has a multipoint configuration file that allows one to serve and build in multiple formats. There is also support for schematics that allows developer to do more post processing of Angular output. Also proxying files, replacing files on build time, and changing which index.html are just to name a few of the delights of working with angular.json. It's just Vite, wrapped with Sullivan paper.

This has an upside, when Vite updates, you don't bother, because Angular framework will do the work out of the box.

Multilingual support

Multilingual in Svelte is available during development, most translation solutions are runtime solutions, where the translations are loaded separately on runtime. Angular provides out of the box solution for localization and internationalization, with great support for things like date format, currencies, and number formats. Angular serves one version at a time. On build-time, it bakes in the language content, so it generates multiple builds, one for each language, and your job is to serve the right build for the language requested by URL. Attractive but heavy.

That was a heavy one, but it left a lot to be said. I decided to give it one more episode to rant one last time about Svelte, vs Angular. 😴

Server Side Rendering and support - Sekrab Garage

Angular vs Svelte. There was much I wanted to say about SSR support but Angular 22 deprecated their CommonEngine and replaced it with AngularNodeAppEngine , I need to hit the drawing board again to replace my single-.... Posted in Angular, Svelte

garage.sekrab.com

When simple is stupid

Ayyash — Tue, 06 Oct 2026 10:05:00 +0000

Angular vs Svelte

Error handling

SvelteKit's model is different by design. No zone, no DI, no interception layer. Errors are caught at whatever boundary happens to enclose them, and each boundary has its own recovery policy.

What you can't do is catch error and keep the page. There's no configuration where SvelteKit reports the error and leaves the tree standing. Angular's ErrorHandler does that; Svelte decided a component that threw an error shouldn't keep rendering.

Svelte Error handling

This causes a bit of fragmentation in Svelte, especially with the fine tuning of error boundaries in templates. Here are the different levels of error handling in Svelte:

starts with boundary (the only error handler that does not throw back a redirect)
load functions returned "error" (Svelte built in object)
client hook handles client-side errors
server hook handles routing, template errors and server-side exceptions
create +error.svelte in the right place to catch the error (for logging issues, or reversal ... etc), these files can be placed anywhere in a tree of a route, to catch errors within context of that branch
finally error.html itself catches everything else
Also, add window event listeners and server event listeners to catch errors the leftovers

In template boundaries:

<!--in your +page.svelte -->
<svelte:boundary>
    normal template content
    {#snippet failed(error, reset)}
         oh oh, stay put, do not redirect to +error.svelte
         this is the only hanlder that stays put
    {/snippet}

</svelte:boundary>

In load functions:

// +page.ts
export const load: PageLoad = async ({params}) => {
  const order = await GetOrder({id: params.id});
  if (!order){
    // throw a native svelte error that is cauthgt by +error or error.html
    error(404, {message: 'Order not found'});
  }
  // ...
}

In client and server error handling hooks

// hooks.client.ts
export const handleError: HandleClientError = async (error) => {
  // catch errors thrown from template rendering that are not caught
  // this also catches unhandled error in case ssr is off, or server handler did not catch error
  // this returns +error.svelte if exists, or error.html
  // error.event has the route and url
  const _error = (<any>error?.error)?.message || error?.message || error;
  return {
    message: _error || 'ERROR',
    source: error.event?.url.pathname
  };
};

// hooks.server.ts
export const handleError: HandleServerError = async (error) => {
  // catch errors on server rendering, that are not handled
  // if this is handled here, client hook does not handle it
  // returns +error.svelte if found, or error.html
  // error.event has the request
  const _error = (<any>error?.error)?.message || error?.message || error;

  return {
    message: _error || 'UNKNOWN ERROR',
    source: error.event?.request?.url
  };
};

The +error.svelte has access to error from the page object. And error.html through %sveltekit.error% directive.

// +error.svelte
import { page } from '$app/state';
// read page.error object if found
console.log(page?.status, page.error?.message, page.error?.source);

// error.html
// no access except to %sveltekit.status%, and %sveltekit.error.message%

If it reaches the last page, it may look like a severe error, but honestly it's just one error that you forgot to handle properly. Svelte could be a total drama queen!

API errors are caught in their fetch handler, or Axios interceptor, or {#await} in templates. But you need to clear out the error and never throw it back, unless you intend to try catch it locally (in template). In fetch you just check response.ok (Axios interception model can be recreated using Svelte fetch but I am too lazy to reinvent such a wheel!)

Of course, this is assuming you never make an explicit http request in a .svelte file. And that you are not Claude.

// axios http.interceptor.ts
export const HttpInterceptor = (httpClient: AxiosInstance) => {
  httpClient.interceptors.response.use(
        null,
        function (error) {
        // pass a custom axios context to decide whether to throw back or handle
        const _context = error.response?.config?.errorContext
        if (_context.throwBack) {
          return Promise.reject(error);
        } else {
          return Promise.resolve(error);
        }
  });
}

// in axiost.d.ts, delcare the extra context
import 'axios';
declare module 'axios' {
  export interface AxiosRequestConfig {
      errorContext?: {
          throwBack?: boolean;
      };
  }
}

// then pass throwBack to http requests to force a throw back, to catch in calling template
await httpClient.post('url', data, {
    errorContext: {
      // let template catch it
      throwBack: true
    }
  });

Finally, there are two extra locations to fine tune error handling, the +layout.svelte, and in your custom Node server,

// +layout.svelte
  onMount(() => {
    window.addEventListener('error', (e) => {
      console.log(e);
    });

    window.addEventListener('unhandledrejection', (e)=>{
      console.log(e);
    });
});

In your Node server:

// index.js before everything
process.on('unhandledRejection', (reason, promise) => {
  console.error('Unhandled Rejection:', reason);
});
process.on('uncaughtException', (err, origin) => {
  console.error('Unhandled Exception:', err);
});

Angular error handling

In Angular, here are the ways to handle errors, which looks similar to Svelte. The boundary is a new addition that acts like Svlete boundary.

template @defer to catch template errors locally
template @boundary (still in preview for version 22)
global ErrorHandler implementation (provided on bootstrap for all browser errors and unhandled rejection events)
routing errors are added directly to route config, navigation events can also be subscribed to at any level to fine tune error handling per route tree.
Left overs on bootstrap level

When using Angular with SSR, Angular automatically adds the unhandledRejection and uncaughtException listeners to the server process. These handlers prevent the server from crashing and instead log captured errors to the console.

Since I have been an Angular developer before I used Svelte, this cost me quite a bunch of server crashes because I didn't know I had to manually add it! You live and you learn.

Template and rendering errors:

// error components can be positioned anywhere, where specific errors can be listered to

// in app.routes configuration file
const MyAppRoutes: Routes = [
 {
    path: '404',
    component: NotFoundComponent,
  },
    // ... routes
  {
    // catch everything else
    path: '**',
    // either redirect to 404
    // redirectTo: '/404',
    // or show component in same url:
    component: NotFoundComponent,
    pathMatch: 'full',
   }
  },

// aslo subscribe to route events head start to catch and log
// provideEnvironmentInitializer(appFactory)
const appFactory = () => {
  const router: Router = inject(Router);
  router.events
    .pipe(
      filter(
        (e) => e instanceof NavigationEnd
      )
    ).subscribe((event) => {
       if (event.urlAfterRedirects === '/404') {
          if (event.url !== '/404') {
              // log 404 error when 404 is redirected to
              console.log('404', event.url);
          }
       }
    });
    // catch NavigationError
    // this can also be done with the withNavigationErrorHandler token
   router.events
    .pipe(filter((e) => e instanceof NavigationError))
    .subscribe((event) => {
      // log unexepected navigation errors
      console.log( 'unexpected error in navigation', event.error);
      // redirect to '/error'
    });
};

// route provider:
const AppRouteProviders = [
  provideEnvironmentInitializer(appFactory),
  provideRouter(
    // routes array:
    MyAppRoutes,
    // catch navigation errors here instead (similar to above event subscriber)
    withNavigationErrorHandler(errorFactory)
  )
];
// Bootstrap error handler, main.ts
bootstrapApplication(AppComponent, {
    providers: [
        ...AppRouteProviders,
        // ask Angular to handle window unhandledrejection and error events
        // via ErrorHandler
        provideBrowserGlobalErrorListeners()
    ]
   })
   // the final left-overs
  .catch((err) => console.log('the left-overs', err));

API errors are caught with the http interceptor, using RxJS catchError operator. See the Http Client context we spoke of last week.

// http interceptor file

const SOMETHING = new HttpContextToken<any>(() => {throwBack: false});

// helper function
export const getErrorContext = (src: any) => {
 return new HttpContext().set(SOMETHING, src);
};

export const OlInterceptorFn: HttpInterceptorFn = (req: HttpRequest<any>, next: HttpHandlerFn) => {
 return next(adjustedReq)
      .pipe(
          // catch all http errors
         catchError((e) => {
            // if context rethrows
            if (req.context.get(SOMETHING)) {
               const throwBack = req.context.get(SOMETHING).throwBack;
               // throw back or clear out
               return throwBack ? throwError(() => e) : of(null);
            }
            // throw back
            return throwError(() => e);

         })

      );
  };

// example http call with throwback, let caller catch it
return this.http.post(Config.API.resource.query, _params, {
     context: getErrorContext({throwBack: true})
});

Conclusion: error handling acts differently in both frameworks, it is more fragmented in Svelte and leaves little room for fine tuning. Also there is manual work and definite missed gaps. The error.html final catch is an obscure dead end. In Angular again the boilerplate is larger, but it can all be handled in less files, and in the same folder, even if triggered on different routes, because routing is not file system based. In addition to the out of the box window and server error handlers that -I must admit- made me dumber!

Forms

Svelte does not get in the way of creating forms, it just provides the binding process, which is quite simple and works with their Runes $state perfectly well. Angular recently adopted the same concept where the form is just an interface, and the real work happens on a signal. But when you start working with validation, you realize you need to retrain your Svelte into understanding Web 101. I recreated the form input like I did in Angular, but the difference is obvious. In Svelte you're dealing with the DOM. No protection. In Angular you use their out of the box directives to enhance an existing form related directive.

Form directive and validation

Here is an example in Angular for a form directive, that builds on top of the validator class, provided out of the box.

export class InputDirective implements Validator {
    readonly validator = input<string>();
    // for example:
    readonly maxLength = input<string>();
    // this injection is quite powerful, to target the content of the directive as Angular DOM
    private el = inject(ElementRef);

    validate(control: AbstractControl): ValidationErrors | null {
      // ... for example
      const maxlength = this.maxlength();
      if (maxlength && control.value) {
          if (Validators.maxLength(maxlength)(control)) {
            this.errorText.set('Too long');
          }
        }
    }
}

Then in form, the following will be validated on input change:

<--olinput is the directive selector -->
<input type="text"
  olinput
  [formControlName]="something"
  [required]="true"
  [maxLength]="30"
/>

Read about the full implementation in Taming Angular Forms.

In Svelte however, deciding which validation rule overrides the other, targeting the HTML input inside the component, and requesting the form validation upon demand, were pain points. The simplicity of code created in Svelte is not worth the trouble.

Bindable values

That being said, creating an immediate state and binding it to any input form, is much easier in Svelte. If you do not wish to control validation or have a simple form, it is useless boilerplate in Angular.

Updating a form input inside a component in Angular is a nightmare that never gets easier. The easiest way is to deal with the component that has a field, is via input and output signals. In Svelte however, all you need is a bindable property.

<form onsubmit={saveForm} novalidate>
  <div class="spaced">
     <Otp bind:value={formState.code} />
  </div>
  <button type="submit" class="btn-rev">SAVE</button>
</form>

Where the Otp component simply looks like this, and that's it. The internal input value is reflected to the external formState.code.

<script>
let {  value = $bindable() }: { value?: any } = $props();
</script>
<input
    type="text"
    bind:value={value}/>

This brings us to the concept of directives. In Svelte, you can call a common javascript function anywhere in the template. You can also attach a behavior fairly easily. But when you need to deal with the outside world or have more accurate life cycle hooks for those attachments, there is nothing that can help. Here is an example:

// lib/lazy.ts
// example svelte attachment
export function lazy(url: string): Attachment {
  return (element: HTMLImageElement) => {
  if (!element) return;

    if (!browser || !IntersectionObserver) {
      element.src = url;
      return;
    }
     // do some intersection observation ...
     return () => {
      // stop watching and destroy
    };
  };
}

A directive in Angular is similar:

@Directive({
    // choose the css selector
    selector: '[olLazy]'
})
// dependecy injection for a safe version of the DOM element
  constructor(
    private el: ElementRef,
    private renderer: Renderer2,

  ) { }

})

export class LazyDirective implements AfterViewInit, OnChanges, OnDestroy {
 ngAfterViewInit() {
     // life cycle hook for first time loading
 }
 ngOnChanges(c: SimpleChanges) {
     // watch changes
 }
 ngOnDestroy(): void {
    // destroy
 }
}

Looks like Angular has much more boilerplate for simple behavior. Wait until you need to detect the server platform:

// inject the actual request from server
private request = inject(REQUEST, { optional: true }) as Request;
// use it in a directive
this.request.get('user-agent')

In Svelte, there is no way to find out the user agent in the context of an attachment. Go ahead, try, then let me know.

Routing

Angular code driven routing benefits over Svelte choice of 1995 style of file-system based routing, hands down, wins my support. Common guys, WordPress friendly routing must have left some mark on your skin!

Creating logic rules embedded in a file name, that can be renames, deleted, or moved, to make room for more rules, is distasteful.

I am going to stop badgering Svelte(kit) now.

Almost everything that can be done in Angular routing, can somehow be reproduced using file-system based routing. On top of that, Angular also provides a Route class that supports the following:

Reuse strategy

Reuse strategy: allows a custom behavior of the route revisited in sequence, it can be used to store data as user reloads the same route with different parameters, or---the more popular need---destroy the route component and rebuild it.

In Svelte, a #key directive in templates destroys that part of the page when the key changes. But it's limited to one key, and it does not come with other less popular features of the Reuse Strategy. There is also the more vague invalidateAll option for the route function. I used it, and I must admit, I still don't know what to expect.

<!--in svelte component -->
{#key id}
    component content here, reload if id changed in same route
{/key}

In Angular, besides the usual async pipes that observe route changes, a higher order reuse strategy can destroy the whole route and recreate it:

// in route reuse class
@Injectable({ providedIn: 'root' })
export class RouteReuseService extends RouteReuseStrategy {
 // ...
  shouldReuseRoute(curr: ActivatedRouteSnapshot, future: ActivatedRouteSnapshot): boolean {
  // example of forcing a route regeneration by route data
  // read route data to figure out what to reuse, the pages that are troublesome should not reuse
  // if data contains "resuse: never" make a check on params values, if changed, return false
  if (future.routeConfig === curr.routeConfig) {
     if (future.data && future.data['reuse'] === 'never') {
        // check all params
        let reuse = true;
        curr.data['params'].forEach((n: string) => {
           // fail if not exact match
           reuse = reuse && curr.paramMap.get(n) === future.paramMap.get(n);
        });
        return reuse;
     }
  }
  // reuse component? or don't reuse it?
  return future.routeConfig === curr.routeConfig;

 }

}

// provide it at boostrap
bootstrapApplication(AppComponent, {
 providers: [
     { provide: RouteReuseStrategy, useClass: RouteReuseService }
 ]
});

// then use in route:
{
    path: ':id',
    component: OrderDetailsComponent,
    data: { reuse: 'never', params: ['id'] },
}

More boilerplate? yes. More control? You bet.

Preloading

In Svelte there is only one data-attribute added in app.html to preload the code, it is not fine tuned, and unpredictable.

In my personal experience, I found out the hard way that the reroute hook runs for every route preload event.

In Angular you can implement a service to choose which routes you need to be preloaded, and optionally fine tune it to preload after a delay.

<!-- sveltekit app.html -->
<body data-sveltekit-preload-code="eager">
</body>

Here is an example of a preload strategy I have always used, to preload modules after a delay, note that the route in current context, does not preload, it simply immediately loads.

// preload strategy class that optionally delays preloaded routes by 5 seconds
export class PreloadService implements PreloadingStrategy {

  preload(route: Route, load: () => Observable<any>): Observable<any> {
    if (route.data?.['preload']) {
      if (route.data['delay']) {
        return timer(5000).pipe(mergeMap(() => load()), catchError(() => of(null)));
      } else {
        return load();
      }
    } else {
      return of(null);
    }
  }
}

// then use per route:
{
    path: 'shippers',
    component: ShippersComponent,
    loadChildren: () =>
       // lazy load the route
       import('./routes/shipper.route').then((m) => m.ShipperRoutes),
    // preload anytime, after 5 seconds
    data: { preload: true, delay: true },
  },

Navigation events

In Svelte, besides the server handler, the +page.ts load events (which are not guaranteed to fire in sequence), onMount and onDestroy for every page, and component, there is also returned destroyers for $effect, and attach. You can watch navigation changes on root +layout.svelte, the object it returns is basic. In Angular, navigation events are observables that can be tapped onto, in root level (before any navigation occurs) and it returns richer information about the route. All components, and directives have onInit and onDestroy. Canceled events can be caught too, and this is where fine tuning error handling shines.

// watch navigation events on +layout.svelte
beforeNavigate((navigation) => {
    const _url = navigation?.to?.url;
    // save url to navigate to, then navigate
    // ...
});

In Angular, the routing events are "provided" on bootstrap, like everything in Angular

// of of the providers array:
provideEnvironmentInitializer () => {
  const router: Router = inject(Router);
  router.events
    .pipe(
      filter(
        (e) =>
          // optionally choose which events to track
          // there are a lot more events available for tracking
          e instanceof NavigationEnd ||
          e instanceof NavigationCancel ||
          e instanceof RouteConfigLoadEnd
      )
    )
    .subscribe((event) => {
      if (event instanceof NavigationEnd) {
        // the event objects holds  alot of information
        if (event.urlAfterRedirects === '/404') {

        }
        const _url = event.url;
        // ...
      } else if (event instanceof NavigationCancel) {
        // this happens when user isn't logged in, the navigation is canceled
        // via the auth guard
        // ...
      }
    });
};

Reroute Hook

This is specific to Svelte. What it does is reroute according to any rule you feed it. I have used that for multi lingual interfaces so that the language is never part of the route system.

// it must be in a file named hook.ts, on root
export const reroute: Reroute = ({ url }) => {
  // catch /en or /ar and remove it to a plain route
  return reroutePath(url.pathname);
};

In Angular there is nothing that I would do for language picker in development, since Angular dev environment has always been built around a single language, where the other languages are produced on build time. But the closest to reroute would probably be UrlSerializer.

Running all languages in development was a blessing in Svelte, until I had to maintain the language on the server, it started turning dark!

Complicated? One look at Route documentation in Angular still intimidates me. I have used only a handful of features, but nevertheless, they are features that proved to be hard to reproduce in Svelte. So simplicity is always appreciated, until you have a complicated situation.

Having free-from-file-system routing, to me, has always won.

It's liberty to organize your project according to functionality, not route.
Allows you to delay decision of routes, while building the business
It makes it easy to reuse components, with minimal conditionals
It centralizes all route-related issues in an explicit manner

And let's not forget, you don't have to rename files to fix a route issue! That is horrific 😱

Projection

In Svelte you are provided with the snippet, which allows you to pass back the container element to process it in the wrapper. But there is no way for the component to know what this snippet has, unless you add enough boilerplate to wait for the snippet to load. There is no hook to tell you that the snippet content is ready.

// in html we render the snippet
{@render input(el => (element = el))}

// in script, find the object
const element = document.getElementById(id);

// to wait for the content to load, you need to bind:this of the snippet content, then pass it back to component, and watch
let element = $state(null);
$effect(() => {
    if (element) {
        // the content is loaded with the exact component inside snippet
    }
});

In HTML:

<!-- then you need to bind that whenever you use it -->
{#snippet input(ref)}
    <div bind:this={ref} class="loaded-box></div>
{/snippet}

This becomes tedious to repeat on every component. $effect too is not an ideal way to watch changes. But it does the job.

In Angular, the boilerplate of the component is inherently defined and bound by the wrapper component, or the directive defined. You can inject the content of the projected content, as a directive or as a component, and wait for the initialization, or hook to some function, or even call a function in the snippet (content island) component. It has the same challenge of choosing the right hook (Angular introduced two extra hooks recently to handle those edge cases), but besides that, the code of Angular does look more complicated. So for simple things it looks like you need to define a bit too many things to get projection working.

// you first use this
template:`<ng-content></ng-content>`;

// selector: ol-input
// then you inject
readonly inputDirective = contentChild(InputDirective);

 // then you watch, in constructor using $effect
  constructor() {
    effect(() => {
      // this targtes HTML element inside the ng-content
      // assume the selector is ol-directive
      const element = this.inputDirective()?.element;
      // ...
    });
  }
}

To use this, it's as simple as adding the directive to the target component projected content.

<ol-input>
this content is projected, with one specific element with a directive that can be singled out and targeted:
    <input ... ol-directive />
</ol-inpit>

I have run into many scenarios when I longed for the complexity of Angular.

To conclude: Svelte indeed has less colors, and sometimes that is an art of its own. But if you want to paint a Monalisa, you need to start mixing those colors manually.

Speaking of life cycle hooks, one more fine Tuesday is coming your way in this series. In addition to overview of SSR, bootstrapping and some badgering. 😴

What about you? Did Angular make you lazier?

Resources

Frontender in the middle

Ayyash — Sun, 27 Sep 2026 12:30:00 +0000

Angular vs Svelte

In this series I break down some of the most used features in front end developments, and how different it is to implement between two worlds: Angular and Svelte (kit).

This is not a competition between Apples and Oranges, but a more contextual comparison of real life scenarios between Angular and Svelte, instead of the quite bland, and scientific comparison I found online. I am the frontend developer, caught in the middle.

The comparison is based on the following topics:

Implementation of shared concepts: forms, projection, error handling, routing ... etc
What out-of-the-box options each support
The ease of use from developer point of view
Since all my projects are small to medium size apps, I have no interest in comparing build time, or code generated, nor DOM performance. I also avoid third-party component as a habit.
Svelte does not have routing feature out of the box, and allows developers to choose their own routing solution, which I find complete waste of time. Thus, this is only about Svelte Kit.

Dependency injection

This is probably the one most underestimated feature in Angular. Not that the concept itself is invented by Angular. Dependency injection has a lot of benefits, the one that stood out for me is how it was like the glue that placed a responsive client-side app together, in Laymen English.

Svelte is simple. It’s too simple. If you write a function in any file, it will be loaded on page initial load. If you call a function outside the hooks, it will be immediately invoked. Take for example, getting configurations and making them ready everywhere.

export const AppConfig = new MyAppConfigClass();

This can be placed anywhere, whenever you use AppConfig the class will be invoked. Not. The class will be invoked even if nothing uses the AppConfig at first load. If that class relies on any other asynchronous operation, it will fail.

Dependency injection in its purest form is creating a static instance, and return it if already instantiated.

// the core seed of an injectable dependency 
export class SomeThing() {
    static _instances: Something;
    static get RootSomething() {
        if (this._instance){
            return this._instance;
        }
        // initiate something the create an class instance, and save
        // this could be a process that calls a backend, awaits, or returns an observable state, a svele readable store
        this._instance = new Something();
    }
}

To use that in Svelte, it is as simple as:

// +page.svelte
const rootSomething = Something.RootSomething.someReadable; // coupd be a store readable

But this is plain. In Angular there is the concept of hierarchal injections. where you can decide which scope to instantiate in, and which instance to use. I have grown a special appreciation to that concept.

@Injectable({providedIn: 'root'})
export class Something() {
    constructor() {
        // first time instatiated, load it up
        this.SetList(['something']); // could be an observable
    }
}

To use that however, is a bit more boilerplate.

// page.ts
somethingService = inject(Something);

// on init 
const someVar = this.somethingService.someObservable;

// or in template
`
  @let something$ = somethingService.someObservable | async;
`

This concept was quite helpful in injecting httpClient instances. Especially when you have multiple API instances. Using Axios client is popular with Svelte. But to make sure the API url is loaded from an external config file, rather than a dumb obsolete .env file (yes the concept is dumb and obsolete), you had to create a wrapper for the instance of the Axios client. In Angular, you can control the the sequence of events through the provideAppInitializer

// angular bootstrapper controls the sequence of boostrapping
bootstrapApplication(AppComponent, {
     providers: [
        provideHttpClient(
            // ...
        ),
        // here, inject the configuration startup 
        provideAppInitializer(configFactory),
        // ...
     ]
})
.catch((err) => console.error(err));

There is much more to dependency injection in Angular, it shines even more as the project scales up, and where microservices and multi-tenant are architectural decisions. Authoring libraries with enough flexibility to adjust behavior, using injection tokens, aligning SSR with the client side, and not having to worry about leakage of an instance, are just part of the bigger picture.

Check the old article on RxJS based state management in Angular.

Http Client

There is none in Sveltekit. They created a simple version of fetch that only works through their own load functions. And as I said above it fails to hydrate more often, because it has strict rules about matching DOM, and status of the Http call, including headers. If it does work however, it is quite slick.

Angular has its own powerful observable-based http client, with interception and hydration support. It can be injected and used anywhere, and there is no difference between client-side and server side. It works on either side. It hydrates more often than it fails, though I did encounter rare occasions where it failed. It is more forgiving but it might be with a performance cost.

Interception

Here is how to properly intercept in Sveltekit.

// in sveltekit page.ts, with load function
export const load: PageLoad = async ({ fetch, params }) => {
    // this is a sveltekit fetch that hydrates, you need pass it along
    let brand = await GetBrand(fetch, params.slug);
    // ...
}

The fetch itself can be then used through a wrapper, like this

// GetBrand in http functions file
async GetBrand(svFetch, slug: string): Promise<IBrand> {

    // getSvelteFetch is the wrapper than handles interception
    const res = await getSvelteFetch(svFetch)(url, {
      method: 'POST',
      body: {slug: params},
    });
    // some response
    return mapResponse(res);
  }

Then in its own function:

// fetch.ts
export const getSvelteFetch = (svelteFetch, root = Config.apiRoot) => {

  return async (...args: any[]) => { 

    const [url, options] = args;
    // prefix with root
    let _url = root + url;
    // add exact headers to hydrate properly, this is tricky as the token
    // is not always available on ssr  
    const _token = 'what are you';
    const _authorization = _token ?  {'Authorization': `Bearer ${_token}`} : null;

    const headers: any = {
      'Content-Type': 'application/json',
      'Accept-Language': Res.language,
      ..._authorization
    };

    // log something if needed
    console.log(options.body);

    // prepare body with json stringify
    const _body = options.body ? { body: JSON.stringify(options.body) } : null;

     try {
      // then use svelte fetch passed 🤷
      const response = await svelteFetch(_url, {
        ...options,
        headers,
        ..._body
      });  

      if (!response.ok) {
        // log errors
        console.log(response.status);
        response.json().then(json => {
          console.log(json);
        });
        return null;
      } else {
        return await response.json();
      }
    } catch (error) {
      console.log(error);
      return null;
    }
  };
};

This function gets intercepted on both client and server side. If you want to use Axios, it has its own interceptor, but no hydration out of the box.

In Angular, it is an out of the box interceptor function:

// in an http.ts file
export const MyInterceptorFn: HttpInterceptorFn = (req: HttpRequest<any>, next: HttpHandlerFn) => {
    // can inject any service in the app
   const authState = inject(AuthState);

   // using a static member of a service is also possible, 
   // because in Angular you can 
   // control how the app is loaded on bootstrap
   const url = ConfigService.Config.API.apiRoot + req.url;

   const adjustedReq = req.clone({ url: url, setHeaders: getHeaders(authState)});  

   // this also allows a cleaner 401 refresh sequence
   return next(adjustedReq)
      .pipe(
          // RxJS pipe work: examples:
         shareReplay(),
         map(response => mapData(response)),
         finalize(() => {
            // may be hide loaded her
         }),
         // custsom pipe to console log
         debug(somemessage, 'p'),
         catchError((e) => {
            // log or throw back ...
            return throwError(() => e);
         })
    );
};

Http Context

Context that is passed into the interceptor are also supported in Angular HttpClient, and not supported at all in SvelteKit fetch. In Axios, the newest version, there is a way to pass context (finally). Here are two snippets for both worlds:

// Angular http.interceptor
// create a token
const SOMETHING = new HttpContextToken<string>(() => '');
// export a function to quickly set it (this isn't required, can be done in the service)
export const getSomethingContext = (src: string) => {
    return new HttpContext().set(SOMETHING, src);
};
// in the http interceptor:
export const MyInterceptorFn: HttpInterceptorFn = (req: HttpRequest<any>, next: HttpHandlerFn) => {
    // ... get context anywhere, example use of an injected loadService
    loaderService.show(req.context.get(SOMETHING));
    return next(adjustedReq).pipe(
        finalize(() => {
            loaderService.hide(req.context.get(LOADING_SOURCE));
         }),
    );
}

// in some service that needs context
 GetOrder(params): Observable<IOrder> {
     // ... use httpClient injected in service
     return this.http.post('url', params, {
        // set context
          context: getSomethingContext('OrderLoad');
        }).pipe(
          map((response) => {
            return mapResponse(response);
          })
        );
 }

In Axios client:

// first delcare the mapping in axios.d.ts
import 'axios';
declare module 'axios' {
  export interface AxiosRequestConfig {
    context?: string;
  }
}

// in an http.interceptor file
export function HttpInterceptor = (httpClient: AxiosInstance) => {

  // request handler
  httpClient.interceptors.request.use(  function (config) {
          // access the context from config
          Loader.show(config.context);
      }, 
      function (error) {
          // access error.request?.config?.context
          Loader.hide(error.request?.config?.context);
          // ...  
      });
  // response handler
  httpClient.interceptors.response.use(
      function (response) {
            // access context from response.config.context
            Loader.hide(response.config?.context);
      },
      function (error: any) {
          // access context from error.response.config.context
         Loader.hide(error.response?.config?.context)
      }
}

// then in the not-so-great Axios instance, create the instance and pass it to interceptor
export const httpClient = axios.create({
    baseURL: '/api'
});
HttpInterceptor(httpClient);


// now in our http request:
export const GetOrder(params): Promise<any> => {

    return await httpClient.post('url', params, {
      context: 'OrderLoad'
    });
}

I prefer the Angular way. Which one do you prefer?

Reactivity

Runes of SvelteKits is provided by the $state object, and its sisters. In Angular that's signals. SvelteKit uses store for readables and writables. Angular uses observables. which relies on RxJS. I tried to create a state management simple class to handle creating lists, and client-side reactivity, and I could not get away with it in simple Runes. So I ended up installing RxJs. Then later resolved to Svelte store. It is doable, but wait till you need to concatMap multiple concurrent http calls. It is you, yourself, and JavaScript.

Here is an example, where search with debounce search is implemented, in pure JavaScript and in RxJS.

const search = writable<string>(null);

const keyword = derived(search,
    (k, set) => {
      if (!k) return;

      const timer = setTimeout(() => {
        const trimmed = k.trim();
        if (trimmed.length >= 3) {
          set(trimmed);
        }
      }, Config.Basic.debounceTime);
      return () => clearTimeout(timer);
    },
    '',
);

const categories: Readable<ICategory[]> = derived([keyword, CategoryListState.RootList.stateList$],
([k, b]) => {
  if (!k) return;
  // this returns a store readable, that loads categories once per project
  return CategoryListState.RootList.FilterByKeyword(b, k.toLowerCase(), Config.Basic.suggestedSize);
    },
    [],
);
Compare that to RxJS

const search$ = new BehaviorSubject<string>(null);

const keyword$ = search$.pipe(
    filter((k) => !!k),
    debounceTime(Config.Basic.debounceTime),
    map((k) => k?.trim()),
    filter((k) => k?.length >= 3),
);
const categories = keyword$.pipe(
    switchMap((keyword) =>
        // this returns an observable
      CategoryListState.RootList.FilterByKeyword(keyword.toLowerCase(), Config.Basic.suggestedSize),
));

RxJS is not luxury.

Template imports

With the new version of SvelteKit, importing components and using them as classes has become easier, but once you import from a file, you can name your component tag anything, and vscode intellisense cannot decide where to import from if it isn't in shared folder, or lib folder. In Angular importing is the usual typescript import. The tag name is already defined in the component, making it impossible to make mistakes.

The two official VS code extensions used for both are: Angular Language Service, and Svelte for VS Code.

Angular: finds your component anywhere.

Svelte: Good luck

On the other hand, using imported artifacts in Svelte is much simpler, because the .svelte path is an HTML template, with script island. While Angular is a script file, with HTML template island. So here are how to use an enum in both versions:

<script lang="ts">
import { EnumSomething } from './models/something.ts';
</script>

{#if someProp === EnumSomething.Value}
It is directly available in template, as everything imported is.
{/if}

In Angular, the imports to the typescript, need to pass over as protected props to the template

// in Angular component class
@import { EnumSomething } from  from './models/something.ts';

// template
template: `@let someProp = myEnumSomething.Value`;

// class, must delare the import as a local property
readonly myEnumSomething = EnumSomething;

After a while, with Config keys, and constants defined elsewhere, and common functions, it becomes tedious.

Error handling

That is a long story, that will have to wait till next episode. In addition to forms, projection, routes, and some venting. 😴

Frontender in the middle - Sekrab Garage

Angular vs Svelte. This is not a competition between Apples and Oranges, but a more contextual comparison of real life scenarios between Angular and Svelte, instead of the quite bland, and scientific comparison I found .... Posted in Angular, Svelte

garage.sekrab.com

Putting Angular Fire Firestore library to use - II

Ayyash — Tue, 04 Feb 2025 10:00:00 +0000

Previously we created our own Firestore getters to return proper observables, using from to change a Promise into a cold observable. Today let's go on with other commands to map our data properly.

Mapping data

Now that we don't rely on rxfire to return mapped document id, we're going to create our own converters.

"Firestore has a built in converter withConverter to map to and from FireStore. No thanks. We'll take it from here."

The getDoc() returns the DocumentSnapshot with id, and data() as above. getDocs() returns a QuerySnapshot with docs array, among other things, which is an array of DocumentSnapshot objects returned. Our category model now looks like this:

// category.model

// mapping new instance
export interface ICategory {
  name: string | null;
  id: string | null;
  key?: string;
}

// static class or export functions, it's a designers choice
export class Category {
  public static NewInstance(data: QueryDocumentSnapshot): ICategory {
    if (data === null) {
      return null;
    }
    const d = data.data();
    return {
      id: data.id,
      name: d['name'],
      key: d['key']
    };
  }

  // receives QuerySnapshot and maps out the `data() ` and id
  public static NewInstances(data: QuerySnapshot): ICategory[] {
    // read docs array 
    return data.docs.map(n => Category.NewInstance(n));
  }

}

So the service call now looks like this:

// category.service

 GetCategories(params: IWhere[] = []): Observable<ICategory[]> {
    // ...
    return from(getDocs(_query)).pipe(
      map((res: QuerySnapshot) => {
        // here map
        return Category.NewInstances(res);
      })
    );
}
GetCategory(id: string): Observable<ICategory> {
    return from(getDoc(doc(this.db, 'categories', id))).pipe(
      map((res: DocumentSnapshot) => {
        // map
        return Category.NewInstance(res);
      }),
    );
}

Let's see what addDoc() returns.

Create document

I created a quick form with name and key, to add category, and a service call to create category:

// components/categories.list

addNew() {
    // read form:
    const newCat: Partial<ICategory> = this.fg.value;

    this.categoryService.CreateCategory(newCat).subscribe({
      next: (res) => {
        // the category list should be updated here
       console.log(res);
      }
    });
}

The service is expected to return an observable, the following may not cut it, the returned object is a DocumentReference which only is a reference to the document created with id.

// category.service
CreateCategory(category: Partial<ICategory>): Observable<any> {
    return from(addDoc(collection(this.db, 'categories'), category)).pipe(
      map(res => {
        // I have nothing but id!
        return {...category, id: res.id};

      })
    );
}

That may look fine, but I do not wish to use id directly without going through our mappers, the solution can be as simple as a separate mapper, or we can slightly adapt the NewInstance

// category.model

// adjust NewInstance to accept partial category
public static NewInstance(data: DocumentSnapshot | Partial<ICategory>, id?: string): ICategory {
    if (data === null) {
      return null;
    }

    const d = data instanceof DocumentSnapshot ? data.data() : data;
    return {
      id: data.id || id, // if data.id doesnt exist (as in addDoc)
      name: d['name'],
      key: d['key']
    };
}

Then in the service call we pass the original category with the returned id

// category.service

CreateCategory(category: Partial<ICategory>): Observable<ICategory> {

    return from(addDoc(collection(this.db, 'categories'), category)).pipe(
      map(res => {
        // update to pass category and res.id
        return Category.NewInstance(category, res.id);
      }),
    );

}

The curious case of Firestore syntax

The following methods are so identical, if you do not make distinction between them you might lose your hair before 50. So I decided to list them, then forget them.

doc(this.db, 'categories', 'SOMEID') returns DocumentReference, of new or existing document
doc(collection(this.db, 'categories')) returns DocumentReference of newly generated ID
setDoc(_DOCUMENT_REFERENCE, {...newCategory}, options) sets the document data, saves with the provided ID in the Document Reference
addDoc(collection(this.db, 'categories'), {...newCategory}); adds a document with an auto generated ID (this is shortcut for doc(collection...) then setDoc())
updateDoc(doc(this.db, 'categories', 'EXISTING_ID'), PARTIAL_CATEGORY) this updates an existing document (a shortcut for doc(db...) then setDoc() with an existing ID)

The confusion stirred up from the first two, they look so similar, but they are different

// Find document reference, or create it with new ID
const categoryRef = doc(this.db, 'categories', '_SomeDocumentReferenceId');

// Create a document reference with auto generated id
const categoryRef = doc(collection(this.db, 'categories'));

Now the returned reference document can be used to create an actual document, or update it. So it is expected to be succeeded with setDoc

// then use the returned reference to setDoc, to add a new document
setDoc(categoryRef, {name: 'Bubbles', key: 'bubbles'});

// pass partial document with options: merge to partially update an existing document
setDoc(existingCategoryRef, {name: 'Bubble'}, {merge: true});

If the document does not exist wit merge set to true, it will create a new document with partial data. Not good. Be careful.

The safe options are the last two:


// add a new documnet with a new generated ID
addDoc(collection(this.db, 'categories'), {name: 'Bubbles', key: 'bubbles'});

// update and existing document, this will throw an error if non existent
updateDoc(existingCategoryRef, {name: 'Bubbles'})

For illustration purposes, here is the other way to create a new category

// an alternative way to create
CreateCategory(category: Partial<ICategory>): Observable<ICategory> {

    // new auto generated id
    const ref = doc(collection(this.db, 'categories'));

    return from(setDoc(ref, category)).pipe(
       map(_ => {
         // response is void, id is in original ref
         return Category.NewInstance(category, ref.id);
       })
    );
}

Update document

Building on the above, I created a quick form for the category details to allow update. I will still pass all fields, but we can always pass partial fields.

// category.sevice

// id must be passed in category
UpdateCategory(category: Partial<ICategory>): Observable<ICategory> {
    return from(updateDoc(doc(this.db, 'categories', category.id), category)).pipe(
      map(_ => {
        // response is void
        // why do we do this? because you never know in the future what other changes you might need to make before returning
        return Category.NewInstance(category);
      })
    );
}

This is a proof of concept, there are ways to tighten the loose ends, like forcing the id to be passed, checking non existent document, returning different shape of data, etc.

To use it, the form is collected, and the id is captured:

// categories/list.component
update(category: ICategory) {
    // gather field values
    const cat: Partial<ICategory> = this.ufg.value;

    // make sure the id is passed
    this.categoryService.UpdateCategory({...cat, id: category.id}).subscribe({
      next: (res) => {
        console.log(res); // this has the same Category after update
      }
    });
  }

Delete document

This one is straight forward, we might choose to return a Boolean for success.

// category.sevice

DeleteCategory(id: string): Observable<boolean> {
    return from(deleteDoc(doc(this.db, 'categories', id))).pipe(
      // response is void, but we might want to differentiate failures later
      map(_ => true)
    );
}

We call it simply by passing ID

// category/list.component

delete(category: ICategory) {
    this.categoryService.DeleteCategory(category.id).subscribe({
      next: (res) => {
        console.log('success!', res);
      }
    });
}

There is no straight forward way to bulk delete. Let's move on.

Querying responsibly

We created an IWhere model to allow any query to be passed to our category list. But we should control the fields to query in our models, and protect our components from field changes. We should also control what can be queried and how, in order to always be ahead of any hidden prices on Firebase.

In our IWhere model, we can add IFieldOptions model. Here is an example of label instead of name, to show how we protect our components from Firestore changes.

// where.model

// the param fields object (yes its plural)
export interface IFieldOptions {
    label?: string; // exmaple
    key?: string;

    // other example fields
    month?: Date;
    recent?: boolean;
    maxPrice?: number;
}


// map fields to where conditions of the proper firestore keys

export const mapListoptions = (options?: IFieldOptions): IWhere[] => {

    let c: any[] = [];
    if (!options) return [];

    if (options.label) {
      // mapping label to name
      c.push({ fieldPath: 'name', opStr: '==', value: options.label });
    }

    if(options.key) {
      c.push({ fieldPath: 'key', opStr: '==', value: options.key });
    }
    // maxPrice is a less than or equal operator
    if (options.maxPrice) {
        c.push({ fieldPath: 'price', opStr: '<=', value: options.maxPrice });
    }

    if (options.month) {
        // to implement, push only data of the same month
        c.push(...mapMonth(options.month));
    }

    if (options.recent) {
        const lastWeek = new Date();
        lastWeek.setDate(lastWeek.getDate() - 7);
        // things that happened since last week:
        c.push({ fieldPath: 'date', opStr: '>=', value: lastWeek });
    }

    return c;
}

The change on our service is like this

// category.sevice

// accept options of specific fields
GetCategories(params?: IFieldOptions): Observable<ICategory[]> {
    // translate fields to where:
    const _where: any[] = (mapFieldOptions(fieldOptions))
        .map(n => where(n.fieldPath, n.opStr, n.value));

    // pass the where to query
    const _query = query(collection(this.db, this._url), ..._where);

    // ... getDocs
}

Here is an example of how to get a group of documents by maximum price:

// example usage
something$ = someService.GetList({maxPrice: 344});

This makes much more sense. I added an example of date, note that operations on JavaScript date works fine, even if the Firestore date is of type Timestamp. The idea of the example is to showcase that the component should not really know the details of the implementation, so getting "most recent documents" for example should be like this

// example
something$ = someService.GetList({recent: true});

The other example is to get month of date, Firestore deals with Javascript date directly:

// where.model

const mapMonth = (month: Date): IWhere[] => {
  const from = new Date(month);
  const to = new Date(month);

  from.setDate(1);
  from.setHours(0, 0, 0, 0);
  to.setMonth(to.getMonth() + 1);
  to.setHours(0, 0, 0, 0); // the edge of next month, is last day this month


  let c: IWhere[] = [

    { fieldPath: 'date', opStr: '>=', value: from },
    { fieldPath: 'date', opStr: '<=', value: to }
  ];

  return c;
};

This works as expected.

Timestamp

Firestore reference of Timestamp.

This class may not make a difference when querying, but if you have a date field, and would like to save user provided date into it, it's best to use Firestore Timestamp class to do the conversion. The difference between Firestore Timestamp and Javascript date is subtle. So subtle I don't even see it! I think it's the ranks of rounding.

// somemodel

// use Timestamp class to map from and to dates

const jsDate = new Date();

// addDoc with
const newData = {
    fbdate: Timestamp.fromDate(jsDate)
}

// DocumentSnapshot returns data() with date field, the type is Timestamp
// use toDate to convert to js Date
return data['fbdate'].toDate();

Firestore Lite

Firebase offers a lite version of Firestore for simple CRUD, so far we have used only those available in lite version. I changed all
import { ... } from '@angular/fire/firestore';
Into
import { ... } from '@angular/fire/firestore/lite';

The build chunk was indeed smaller. The main chunk that was reduced in my personal project, came down from 502 KB to 352 KB.

Interception

With httpClient we used an interception function to add the loading effect, so how do we do that with our solution? We can funnel all calls to one http service that takes care of it. Our new service should be something around this:

// http.service

@Injectable({ providedIn: 'root' })
export class HttpService {
  public run(fn: Observable<any>): Observable<any> {

    // show loader here
    showloader();

    // return function as is
    return fn
      .pipe(
        // hide loader
        finalize(() => hideloader()),
        // debug and catchErrors as well here
      );
  }
}

Then in the service

// category.service

private httpService = inject(HttpService);

GetCategories(params?: IWhere[]): Observable<ICategory[]> {
    // ...
    // wrap in run
    return this.httpService.run(from(getDocs(q)).pipe(
      map((res: QuerySnapshot) => {
        return Category.NewInstances(res);
      })
    ));
}

One design problem in the above is the loss of type checking because the inner function returns observable<any>. This can be fixed with a generic

// http.service
// ...
public run<T>(fn: Observable<any>): Observable<T> {
    // ...
}

Then call it like this:

// category.service
return this.httpService.run<ICategory[]>(from(getDocs(q)).pipe(
  map((res: QuerySnapshot) => {
    return Category.NewInstances(res);
  })
));

Have a look at the loading effect we created previously using state management. All we need is to inject the state service, then call show and hide. This uses good ol' RxJs, I looked into Signals, and could not see how it would replace RxJs without making a big mess. May be one fine Tuesday.

That's it. Don't lose hair before 50.

Did you catch the pants on fire? Keep talking. It's not over yet.

Resources

Creating a loading effect using RxJs in Angular

Putting Angular Fire Firestore library to use - II - Sekrab Garage

Angular Firebase Firestore. Previously we created our own Firestore getters to return proper observables, using from to change a Promise into a cold observable. Today let's go on with other commands to map our data properly.Ma.... Posted in Angular, Design

garage.sekrab.com

Putting Angular Fire Firestore library to use - I

Ayyash — Tue, 28 Jan 2025 10:00:00 +0000

In this series, we're going to setup a project that uses a Firebase Firestore to list, create, and edit documents, in Angular. This article:

... is about Angular project architecture, about observables, and promises
... is not about Firebase setup or maintenance
... is not about firebase authentication (find here)
... uses the official @angular/fire package

With the latest Angular update, along with Angular Fire, was kind of depressing. I understand the need to be ever-green, I just don't understand throwing away a syntax that works, for another trendy syntax! But, here we are.

Setup

Here find a link to Firebase Firestore setup, and to Angular Fire setup.

Follow along this project on StackBlitz. I removed Firebase configuration so it won't run properly.

Let's create a project that lists cateogires, where every category is made up of:

name
key

Like this

The main.ts contains the bootstrapper as follows:

// main.ts 

// pay attention to where the imports are from, it should from @angular/fire
import { initializeApp, provideFirebaseApp } from '@angular/fire/app';
import { getFirestore, provideFirestore } from '@angular/fire/firestore';

const fbApp = () => initializeApp({
    //... firebaseConfig here
});
// ... optionally add authentication 

const firebaseProviders = [
  provideFirebaseApp(fbApp),
  provideFirestore(() => getFirestore()),
];

bootstrapApplication(AppComponent, {
  providers: [
    ...firebaseProviders,
    // ...otherpoviders
  ]
})

The Firestore reference

Angular Fire library initializes the db using getFirestore(app); and makes it available for injection.

In a service; the category service, the class looks like this

// services/category.service.ts

@Injectable({ providedIn: 'root' })
export class CategoryService {
    // inject
    private db: Firestore = inject(Firestore);
}

The db is ready to be used in categoryService.

Note about referencing the right SDK

If you run into this error:

"FirebaseError: Type does not match the expected instance. Did you pass a reference from a different Firestore SDK?"

Make sure you were using the latest Firebase libraries. The ones that worked for me were firebase 11.2.0 and @angular/fire 19.0.0 along with @angular/core 19.0.6 minimum.

Get data

Working backwards, what we want to end up with is a component that consumes a returned list as follows:

// a consuming component, like categories list

@Component({
    //...
    template: `@let cats = categories$ | async`
})
export class CategoryListComponent implements OnInit {

    // example
    categories$: Observable<ICategory[]>;
    private categoryService = inject(CategoryService);

    ngOnInit(): void {
        // get categories from service, I expecct an observable I can async to
        this.categories$ = this.categoryService.GetCategories();
    }
}

To get data we use collectionData which returns and observable. The collection function itself returns a reference to the collection.

// services/category.service.ts

@Injectable({ providedIn: 'root' })
export class CategoryService {
    // inject, or via constructor
    private db: Firestore = inject(Firestore);

    GetCategories(): Observable<ICategory[]> {
        // collectionData returns a hot observable
        return collectionData(collection(this.db, 'categories')).pipe(
            map((response: any) => {
                // map the returnd docs into your ICategory
                // i am not including this part here
                return Category.NewInstances(response);
            })
        );
    }
}

did you know you can import from @angular/fire/firestore/lite instead? This is firestore lite library for simple REST and GRUD actions.

The collectionData itself is an HOT observable exported from the rxfire library by Firebase. The following list is already wrapped and exported by @angular/fire

// wrapped and exported by angular fire, from rxFire
  auditTrail,
  collection,
  collectionChanges,
  collectionCount,
  collectionCountSnap,
  collectionData,
  doc,
  docData,
  fromRef,
  snapToData,
  sortedChanges

The returned observable is hot, it's actually so hot, it's cross user, cross browser. Which is not ideal in most of the cases. Under the hood: I spotted this line in the rxfire library
RxFire ref: import('firebase/database').Query,

Yes, they import from the real-time database!

One way to fix that is to pipe to take(1) or first()

// categories.service

GetCategories(): Observable<ICategory[]> {
    // collectionData returns a hot observable
    return collectionData(collection(this.db, 'categories')).pipe(
        // turn off
        first(),
        map((response: any) => {
            // ...
        })
    );
}

Later we'll figure out a better way.

Getting the document id

The above returns an array of categories without document id.. Let's compare the official documentation with that of AngularFire. According to Firestore documentation

// as documented
getDocs(collection(this.db, 'categories')).then(
  (s) => {
    // this returns .id, and .data()
    s.forEach(f => console.log(f.id))
  }
);

Our solution uses rxFire collectionData, which under the hood is an observable wrapped around DocumentSnapshot The function expects options that can have a mapper to the idField, which is a way to wrap both id and data() in one object. One of Firebase's mysteries!

// services/category.service.ts

GetCategories(): Observable<ICategory[]> {
    // map id as well with idField
    return collectionData(collection(this.db, 'categories'), {idField: 'id'}).pipe(
        // turn off hot observable
        first(),
        // ... map
    );
}

We can use the result to build our list, with links to every category.

// category/list.component
template:`@let cats = categories$ | async;
<ul>
  <li *ngFor="let cat of cats">
    <a (click)="select(cat)">{{cat.name}}</a>
  </li>
</ul>

<div class="c-6 box bg-white" *ngIf="selected$ | async as cat">
    selected Category: {{cat | json}}
</div>
`

selected$: Observable<ICategory>;

select(category: ICategory) {
    // to implement GetCategory
    this.selected$ = this.categoryService.GetCategory(category.id);
}

Get by document ID

To get a single category by document ID, according to AngulareFire, you just pass categories/:id. But that isn't how it looks.

I get a different hint in the official documentation

const docRef = doc(db, "cities", "SF");
const docSnap = await getDoc(docRef);

You can always think of collection is the table, and doc as the single row.

To get a collection, or a sub collection, use collectionData with URL syntax that has odd number of segments
categories/:id/something

To get a document, anywhere, we must use docData, and the URL should have even number of segments
categories/:id/something/:somethingid

So if you do not adhere to the number of segments in the URL, for example using collectionData to get two segments, you will get funny error messages like this:

Collection references must have an odd number of segments, but categories/RG3e5jWzithsEzoPWBag has 2.

The right way is to use doc and docData instead.

// category.service
GetCategory(id: string): Observable<ICategory> {
    // pass url: categories/:id, or pass arguments separately
    return docData(doc(this.db, 'categories', id), { idField: 'id' }).pipe(
      first(),
      // ... map
    );
}

Query

To get a list of categories based on any criteria, we use query, then collectionData. The result is always an array.

// category.service

// query to get all categories
const _query = query(collection(this.db, 'categories'))

return collectionData(_query, { idField: 'id' }).pipe(
    first(),
  // ... map
);

Adding a where condition of multiple fields, the default is an AND operator, the reference format is query(ref, where(), where() ...)

// categories.service

// multiple field where condition
GetCategories(params: IWhere[]): Observable<ICategory[]> {

    // turn params into an array of where conditions, then expand it
    const _query = query(collection(this.db, 'categories'), 
    ...params.map(n => where(n.fieldPath, n.opStr, n.value))
    );

    return collectionData(_query).pipe(
        first(),
        // ... map
    );
}

The or format looks like this: query(ref, or(where(), where() ...), and a combination may look like this query(ref, and(where(), where(), or(where(), where()...) ...)

Find reference here

Now the where conditions are made up of three segments: field, operator, value. So in another model file, we define the interface:

// where.model.ts
export type IWhereOp =
    | '<'
    | '<='
    | '=='
    | '!=' // be careful, some operators are not free
    | '>='
    | '>'
    | 'array-contains'
    | 'in' 
    | 'array-contains-any'
    | 'not-in';

export interface IWhere {
    fieldPath: string;
    opStr: IWhereOp;
    value?: any;
}

To use it, we pass the where conditions:

// categories/list.component

this.categories$ = this.categoryService.GetCategories(
    [
        {fieldPath: 'key', opStr: '==', value: 'household'}
    ]
);

This looks ugly all around. Later we'll figure out a more useful way.

Creating a new category is passing the object to addDoc, but the catch is, there is no observable to watch. This is a Promise. But we want an observable so we can pipe to properly.

At this stage, I want to stop and take a step back. The above solutions used rxfire observables, which are all hot. It is not ideal to keep hot observables when dealing with a very expensive service like Firestore. We used first to cool it off. But let's try something different. In order to use with all actions.

Cold observables

Using collectionData and docData is a bit disappointing, because not all actions are wrapped inside of it, and they are hot! We can use from. Or defer if we use then directly. Let me show you both ways:

Using from

// categories.service

// getDocs imported from @angular/fire
// get data with "from"
return from(getDocs(q)).pipe(
  map((s: any) => {
    // s is a querysnapshot that has forEach method
    s.forEach(n => console.log(n.data()));
    // we'll map later
    return s;
  })
);

Or you can use then directly if you remember to defer in RxJs (because then invokes an immediate call):

// categories.sevice

// a different way
const docs = () => getDocs(q).then(s => {
  console.log(s);
  return s;
});

// return a defer in order to subscribe to
return defer(docs)

I like the from way. So I am sticking to it

Mapping data

Let's figure out a way to:

map our data properly with document ID
show a loading effect (yes)

Before we go on, let's see if that fixed the add document mess:

// categories.service

  CreateCategory(category: Partial<ICategory>): Observable<any> {
    return from(addDoc(collection(this.db, 'categories'), category));
    // todo: proper mapping
  }

Yup, this works as expected. But there are other ways to add documents. Next Tuesday inshallah. 😴

Did you know that the IOF destroyed 80% of Gaza? But Gaza will recover.

References:

garage.sekrab.com

Angular Firebase Authentication Update: v.19

Ayyash — Tue, 21 Jan 2025 10:15:00 +0000

Last time we had Firebase Auth integrated at Angular 17. Here is a quick update to keep it fresh in Angular 19.

Providers

Before update, our main.ts looked like this

// main.ts before
const fbApp = () => initializeApp(firebaeConfigHere);
const authApp = () => initializeAuth(fbApp(), {
  persistence: browserSessionPersistence,
  popupRedirectResolver: browserPopupRedirectResolver
});

const firebaseProviders: EnvironmentProviders = importProvidersFrom([
  provideFirebaseApp(fbApp),
  provideAuth(authApp),
]);

bootstrapApplication(AppComponent, {
  providers: [
      // ...
    firebaseProviders
  ],
});

The updates touch the importProvidersFrom, it not longer is needed

// main.ts thew new

const firebaseProviders = [
  provideFirebaseApp(fbApp),
  provideAuth(authApp),
];

bootstrapApplication(AppComponent, {
  providers: [
    // expand it
    ...firebaseProviders
  ],
});

APP_INITIALIZER token

One way to inject the AuthState on application start was to use the APP_INITIALIZER token with no return, and one injection, like this

  {
    provide: APP_INITIALIZER,
    // dummy factory
    useFactory: () => () => {},
    multi: true,
    // injected depdencies, this will be constructed immidiately
    deps: [AuthState],
  },

This simply becomes this:

// new provider
  provideAppInitializer(() => {
    inject(AuthState);
    return null;
  }),

That's it. Looks like the new Firebase library still works as designed.

Validation style final tweaks

Ayyash — Fri, 17 Jan 2025 10:00:00 +0000

To add the missing styles to make it as functional as possible, need to keep reminding ourselves of a golden rule:

Do not assume.

This means we can add relative paddings and margins, borders and colors, using CSS variables, but we cannot dictate how the checkbox should look like. That’s a project style, not an element style. (There are schools like material design that stuff their noses into every element, making it impossible to use single components individually.)

Checkbox

Starting with the checkbox, all we need to do is swap locations of checkbox and label. Then just let the outer project design its own checkbox instead. There are two solutions, a smart one, and a too smart one. The too smart one looks like this:

.cr-field {
   /* target previous silbing */
  .cr-label:has(~ [type="checkbox"]) {
    /* important to remove transform in all cases */
    transform: none!important;
    inset-block-start: 0;
    inset-inline-start: 0;
    padding-inline-start: 1.8rem;
    position: relative;
    display: inline-block;
    background: none;
    cursor: pointer;
  }

  .cr-input[type="checkbox"] {
    position: absolute;
    inset-inline-start: 0;
  }
}

The simpler way is to introduce a new type property for the cr-field directly, assigned explicitly. Implicit assignment is also "too smart."

// input.partial
template: `
    <div class="{{ cssPrefix }}-field {{ typeCss }}" [class.cr-invalid-form]="invalidForm">
    // ...
`
@Input() type!: string;

get typeCss(): string {
    return this.type ? `${this.cssPrefix}-${this.type}` : '';
}

Then we write a not too-smart CSS:

.cr-field.cr-checkbox {
  .cr-label {
   /* same as above */
  }
  .cr-input {
   /* same as above */
  }
}

The selector is simpler and we have a bit more room to style other things, like the required asterisk, the help text, and the feedback text. See, sometimes it pays off to be dumber.

The CSS for this solution:

.cr-field.cr-checkbox {
  .cr-label {
    /* important to remove transform in all cases */
    transform: none!important;
    inset-block-start: 0;
    inset-inline-start: 0;
    padding-inline-start: 1.8rem;
    position: relative;
    display: inline-block;
    background: none;
    cursor: pointer;
  }
  .cr-input {
    position: absolute;
    inset-inline-start: 0;
  }
  .cr-feedback {
    margin-block-start: 0;
    float: none;
  }
  .cr-required {
    position: static;
  }
}

Testing the edges

One of the scenarios we went through is where the required asterisk was out of view, we already designed it to be positioned on the extreme right. With what we have so far, can we make it look good without touching the library component and shared css?

Here is the example of Expiry date, the solution to place the asterisk within context is simply add enough style to the container.

/* fix the container width to be c-5 and display block */
<cr-input placeholder="Expiration" error="Add a date in the future" class="c-5 dblock">
  <input type="hidden" crinput id="mmyy" [required]="true" pattern="[0-9]{4}" formControlName="mmyy" />
  /* also fix the width of inner fields to c-6 */
  <cr-product-expiry (onValue)="expirationValue($event)"></cr-product-expiry>
</cr-input>

The result is like this:

Three things I’ve done:

Changed the container width to be at the percentage width I desired, and changed its display to block (Angular components display by default as contents )
I changed the inner component width to be 50% each (makes more sense)
Then changed the message to: Add a date in the future. This covers both rules: expired date and required value.

So our component held. No changes needed. That is a victory.

You may need to test extra scenarios and update the input css to be as simple as possible, so that it won’t break in the future.

Testing another edge case: Nice looking checkbox

Here is another edge case. Every project has its own style for checkboxes. Given the CSS we have developed thus far, let's see if we can push our single checkbox from the outside world without breaking it. Let's use MDN example.

/* adding the same css with a proper random selector to our project */
.gr-something .cr-field.cr-checkbox {

  .cr-input {
    /* remove default appearance **/
    appearance: none;
    width: 44px;
    height: 24px;
    border-radius: 12px;
    transition: all 0.4s;
  }
  .cr-input::before {
    width: 16px;
    height: 16px;
    border-radius: 9px;
    background-color: var(--sh-black, #000);
    content: '';
    position: absolute;
    inset-block-start: 3px;
    inset-inline-start: 4px;
    transition: all 0.4s;
  }
  .cr-input:checked {
    background-color: var(--sh-yellow, #ffaa00);
    transition: all 0.4s;
  }
  .cr-input:checked::before {
    inset-inline-start: 22px;
    transition: all 0.4s;
  }
  .cr-label {
    /* adjust padding of label */
    padding-inline-start: 4.2rem;
  }
}

The above is the MDN example with few adjustments. We just had to pay attention to the selector so that we don't resolve to !important issues. Applying it is as easy as applying class to selector:

<cr-input  type="checkbox" class="gr-something" ...>
    <input type="checkbox" crinput  ...>
</cr-input>

This looks like the following:

Another victory! See, if we were too smart about our selectors, this would have turned into spaghetti.

Hidden fields

Hidden inputs simplify validation, that would otherwise be challenging. If the validation is within context of the cr-field it’s straight forward, like our previous example of the Expiration date.

<cr-input placeholder="Expiration" error="This is expired">
  <input type="hidden" crinput id="mmyy" pattern="[0-9]{4}" formControlName="mmyy" />
  // some component with MM and YY fields
  <cr-product-expiry (onValue)="expirationValue($event)"></cr-product-expiry>
</cr-input>

If the hidden input is not within context of a field, and it carries out a cross-form update and validation, then the cr-field has nothing but the feedback. The solution is to introduce the type hidden.

Here is a quick example, let’s say if the operating system is MAC, the minimum version is 5.

// example form components
<div class="spaced">
  <cr-input placeholder="Operating system">
    <select crinput id="os" formControlName="os" [required]="true" (change)="updatePlug()">
      <option value="">Select</option>
      <option value="1">Windows</option>
      <option value="2">Mac</option>
      <option value="3">Linux</option>
      <option value="4">Android</option>
    </select>
  </cr-input>
</div>

<cr-input placeholder="Version">
  <input crinput type="number" id="version" formControlName="version" (change)="updatePlug()" />
  <ng-container helptext>OS version</ng-container>
</cr-input>

Updating the fields updates a hidden field plugs with either a value or null

template: `  
// ...
<cr-input placeholder="" error="Not allowed to have Mac version less than 5">
  <input type="hidden" crinput id="plugs" formControlName="plugs" [required]="true" >
</cr-input>`

// in code
updatePlug() {
  // on change of form input, update hidden field
  const os = this.fg.get('os').value;
  const version = this.fg.get('version').value;
  if (os === '2' && version < 5) {
    this.fg.get('plugs').setValue(null);
  } else {
    this.fg.get('plugs').setValue('plug'+ os + version);
  }
}

So the only thing I want to take care of is hiding the required asterisk, and making the feedback more of a none-floating element. Any other styling, need to happen outside the component.

// let's pass type:hidden
<cr-input type="hidden" error="Not allowed to have Mac version less than 5">
  <input type="hidden" crinput id="plugs" formControlName="plugs" [required]="true" >
</cr-input>

And we cater for the cr-hidden style:

// input.css
.cr-field.cr-hidden {
  .cr-label {
    display: none;
  }
  .cr-input[required] ~ .cr-required {
    display: none;
  }
  .cr-feedback {
    float: none;
    margin-block-start: 0;
    margin-inline-start: 0;
  }
}

This will look like this

Of course, my validation is a bit dumbed down for demonstration purposes. The hidden field can have any validation (a pattern for example), you can use setErrors instead of setValue, and you can customize the error message accordingly. That would not affect the CSS though.

Auto-filled fields

The last problem to fix is auto-filled fields, like username and password, where you don’t want the placeholder label to appear on top of the field. Ever. To fix that we introduce a new type static to prevent the floating animation.

Although this isn't stubborn but it would be nice to have another style for none-floating labels in general.

<cr-input placeholder="Username" type="static">
    <input crinput type="text" autocomplete="username" id="username"
     formControlName="username" [required]="true" />
</cr-input>
<cr-input placeholder="Password" type="static">
    <input crinput type="password" autocomplete="current-password" id="pwd" 
    formControlName="pwd" [required]="true" />
</cr-input>

The CSS then defines the new type:

/* input.css */
.cr-field.cr-static {
  /* force floating label even if empty */
  .cr-label:has(~ .cr-input:placeholder-shown) {
    transform: translateY(-100%) scale(0.8);
  }
}

And this is as good as it gets. Notice that if emptied, that label will not float inside the field. Meh, cheap price.

That's it. This is a wrap.

Bonus: standalone imports

Another thing we can do to make this easier to use, is place them in an exported const to import together.

export const InputComponent = [
  InputDirective,
  CrInputPartial
];

Then we can import then together

// in our component
// ...
imports: [...InputComponent],

Conclusion

To recap, the initial target was the following:

Use native HTML input elements.
We did, with only the introduction a formControlName and a directive
Validation rules should be kept to minimum
We only manipulated the error message, and contained basic patterns and common functions
Keep the Angular form loose (do not reinvent the wheel)
The input is content-projected, it belongs to the original form
Use attributes instead of Form builder (unobtrusive)
A directive that reads different attributes was accomplished
Keep form submission loose to allow as much flexibility
Since the form is not part of our directive, nothing is imposed on it
Minimum styling allowing full replacement.
We tried. I think we managed.

That's it. Let Gaza Live.

Resources

StackBlitz project

Validation style final tweaks - Sekrab Garage

Taming Angular forms. To add the missing styles to make it as functional as possible, need to keep reminding ourselves of a golden rule:Do not assume.This means we can add relative paddings and margins, borders and colors,.... Posted in Angular, Design

garage.sekrab.com

Angular validation common functions

Ayyash — Wed, 15 Jan 2025 10:00:00 +0000

There are some repetitive validation functions that I would like to move for their own common file, after which, I want to turn the validation function into another unobtrusive pattern.

The final result should look like this

<cr-input placeholder="placeholder">
  <input crinput ... validator="functionName" />
</cr-input>

Let’s create popular validators and see what it takes.

Date

The date and time fields are handled by browsers pretty well; they don’t need a lot of work. What we need to cover in our patterns is future dates, past dates, and date ranges.

// final result I want to work with
<cr-input placeholder="When?">
  <input crinput type="date" id="appointment" formControlName="appointment" 
    validator="future" />
  <ng-container helptext>Future date</ng-container>
</cr-input>

Let’s change validator attribute into a validation function. We will follow the same method of patterns.

// new validators.ts

export const futureValidator = (control: AbstractControl): ValidationErrors | null => {
  // date is yyyy-mm-dd, should be int eh future
  const today = Date.now();

  if (!control.value) return null;
  const value = new Date(control.value);

  if (!value || +value > +today) {
    return null;
  }
  return {
    future: true
  };
};

// create a map to use globally
export const InputValidators = new Map<string, ValidatorFn>([
  ['future', futureValidator],
]);

In the directive, we’ll check if the validation function already exists. If not, we’ll add it.

// input.directive

// add a new input
@Input() validator?: string;

// in validate handler, just add it
validate(control: AbstractControl): ValidationErrors | null {

  if (this.validator) {
    const _validator = InputValidators.get(this.validator);
    if (_validator && !control.hasValidator(_validator)) {
      control.addValidators(_validator);
    }
  }
  // ... 
}

There is another way to access the form input. However, it relies on having formControl defined and casting an Abstract control to a Form control. It’s ugly. And dependent on the form itself. I’m not using.

That’s it. We don’t need to validate. Then we just need to add a custom error message every time. For now that’s fine.

<cr-input placeholder="When?" error="Required and must be in the future">
  <input crinput type="date" id="appointment" formControlName="appointment" 
    validator="future" [required]="true" />
  <ng-container helptext>Future date</ng-container>
</cr-input>

A past date is straight forward.

Enrich the inline validator

We can improve it a bit, let’s pass parameters unobtrusively too, like this

<input crinput type="date" id="birthdate" formControlName="birthdate" validator="pastFn"
[params]="{date: someDate}"  />

someDate = new Date(2000, 1, 1);

That is what I call garnish, let’s add it, but let’s be very careful. If we ever have to fix a bug in it, we roll back to good old custom validation. I fixed a couple as I was writing this article! I suggest you implement your favorite method.

 // input.directive
@Input() validator?: string;
@Input() params?: any;

validate(control: AbstractControl): ValidationErrors | null {
    if (this.validator) {
        const _validator = InputValidators.get(this.validator);
        if (_validator && !control.hasValidator(_validator)) {
            // if params: apply function (note here params is no longer optional)
            if (this.params) {
                control.addValidators(_validator(this.params));
            } else {
                control.addValidators(_validator);
            }
        }
    }
    // ...
}

Then in our validators collection, wrap the function in another function to pass the arguments. Notice how I choose to name it with Fn suffix, to remind myself it's a function that needs params. (We might enhance by making the params optional and have a different check, but I am not well motivated to do that.)

// vaidtaors.ts

// example pastvalidation with date
export const pastValidatorFn = (params: {date: string}): ValidatorFn => {
  return (control: AbstractControl): ValidationErrors | null => {
    if (!control.value) return null;

    const _date = makeDate(params.date);
    if(!_date) return null;

    const value = new Date(control.value);
    if (!value || +value < +_date) {
      return null;
    }
    return {
      past: true
    };
  };
};

// add to collection, the second argument of map is "any"
// if you want to reach 50s without a heart attack
export const InputValidators = new Map<string, any >([
    // ...
  ['pastFn', pastValidatorFn],
]);

So far so good. The date range should now be easy, all we need to do is update the validation functions to accept two parameters, minimum and maximum. If one is null, it’s ever.

// validator.ts
// A generic function for date ranges, fix it as you see fit
export const dateRangeValidatorFn = (params: {minDate?: string, maxDate?: string}): ValidatorFn => {
  return (control: AbstractControl): ValidationErrors | null => {
    if (!control.value) return null;

    // make two dates if one is null, the other takes over, if both null, return null.
    const _min = makeDate(params.minDate);
    const _max = makeDate(params.maxDate);
    if (!_min && !_max) return null;

    // if both exist, range
    // if only one exists, check against that
    const _minDate = _min ? +_min : null;
    const _maxDate = _max ? +_max : null;
    const value = +(new Date(control.value));

    const future = _maxDate ? value < _maxDate : true;
    const past = value > _minDate; // null is also zero, so this works
    if (future && past) {
      return null;
    }

    return {
      dateRange: true
    };
  };
};

// add to map
export const InputValidators = new Map<string, ValidatorFn>([
    // ...
  ['dateRangeFn', dateRangeValidatorFn],
]);

Since we are passing params as an object, there is enough dynamic behavior to it, but I haven’t fully tested it.

Form component

<cr-input placeholder="Date range" error="Out of range">
    <input crinput type="date" id="daterange" class="w100" formControlName="daterange" [params]="params" validator="dateRangeFn"  />
    <ng-container helptext>Between 1 Jan 2024 - 1 Jan 2025</ng-container>
</cr-input>

minDate = new Date(2024, 0, 1);
maxDate = new Date(2025, 0, 1);
params = { minDate: this.minDate, maxDate: this.maxDate };

A date range selector.

Oh no. Use easypick. By far the least obtrusive. I hope they continue the path of “keeping this dead simple”

Password

To do this properly in our new validators shared function, it needs to pass the other field value dynamically. So we start with a function and a param.

// in the new validators.ts
export const matchPasswordFn = (pwd: AbstractControl): ValidatorFn => {
  return (control: AbstractControl): ValidationErrors | null => {
    // get password and match, if equal return null
    if (control?.value === pwd?.value) {
      return null;
    }
    return {
      matchPassword: true
    };
  };
};

The two fields in our component before using the validator property looks like this

// compontent
template: `
  <cr-input placeholder="Password">
     <!-- update validity on change -->
     <input crinput type="password" id="pwd" (change)="fg?.get('pwd2')?.updateValueAndValidity()"
     formControlName="pwd" crpattern="password" [required]="true" />
    <ng-container helptext>Alphanumeric and special characters, 8 characters minimum</ng-container>
  </cr-input>

  <cr-input placeholder="Confirm password" error="Does not match" >
    <input crinput type="password" id="pwd2" formControlName="pwd2" [required]="true" />
    <ng-container helptext>Should match password</ng-container>
  </cr-input>`

  // in class, before 
  ngOnInit() {
    this.fg = this.fb.group({
      pwd: [''],
      // this won't work
      // pwd2: ['', matchPasswordFn(this.fg.get('pwd')],
      pwd2: ['']
    });

    // this will (import from validators)
    this.fg.get('pwd2').setValidators(matchPasswordFn(this.fg.get('pwd')));
  }

Few things to notice:

Setting the validator directly in the form builder won’t work, because we need to access the form itself, which is not yet available.
We could have done a cross-form validation!
But because we did not, we needed to update validity of pwd2, whenever pwd changed. This is just to be as flexible as one can be.

We can import the matchPasswordFn directly from our validators function, but we can also use the validator property as follows:

// component

<cr-input placeholder="Confirm password" error="Does not match" >
    <!-- add the validator function directly -->
    <input crinput formControlName="pwd2" ...
        validator="matchPassword"
        [params]="fg?.get('pwd')"
    />
</cr-input>

And then the same validation function can be used.

Upload

We begin with a file input that is required. It does not look great, but I will not force it to look any different because every project will has its own unique look for this field. Some might also allow drag and drop, or paste. So we’ll focus on the basics.

Format and required validations are easy. We can create a general image pattern in our patterns list. Adding accept attribute is an additional friendly feature.

// patterns
export const InputPatterns = new Map<string, any>([
 //...
  ['image', '.+\\\\.{1}(jpg|png|gif|bmp)$'],
]);

The component looks like this

// component
<cr-input placeholder="Upload document">
  <input crinput type="file" id="file" formControlName="doc" crpattern="image"
  [attr.accept]="someArray" />
  <ng-container helptext>JPG, PNG only. 1 MB max.</ng-container>
</cr-input>

And it looks like this

The size is a bit harder to capture. But we can still use what we have. A new validation function that accepts two parameters, one for the maximum size, and one for the file size.

// validators
// validate file size to be what?
export const sizeValidatorFn = (params: {size: number, max: number}): ValidatorFn => {
  return (control: AbstractControl): ValidationErrors | null => {
    if (!control.value) return null;
    // convert max from KB to bytes
    const _max = params.max * 1024;
    if (params.size > _max) {
      return {
        size: true
      };
    }

    return null;
  };
};

export const InputValidators = new Map<string, any >([
 // ...
  ['sizeFn', sizeValidatorFn]
]);

And to use it, we need something like this

// component
template: `<cr-input placeholder="Upload document" error="Invalid format or size">
  <input crinput type="file" id="file" class="w100" formControlName="doc" crpattern="image"
   #f validator="sizeFn" [params]="fparams" (change)="updateSize(f)" />
  <ng-container helptext>JPG, PNG only. 1 MB max.</ng-container>
</cr-input>`

fparams: { size: number, max: number };
this.fg = this.fb.group({
  doc: [],
});
updateSize(f: HTMLInputElement) {
    // update the params, then update validity
    // because files is not an immidiate property of formControl
    this.fparams.size = f.files[0]?.size;
    this.fg.get('doc').updateValueAndValidity();
}

This works as expected, but I think we can do better. The file input field is usually not part of the form, because the trend is to upload the file first to the cloud, then update our server record with the returned file unique identifier. We'll leave that to one fine Tuesday.

At least one

Let's add the "at least one" for group of checkboxes in there too.

// validators.ts
export const atleastOne = (control: AbstractControl): ValidationErrors | null => {
  // if all controls are false, return error

  const values = Object.values(control.value);
  if (values.some(v => v === true)) {
    return null;
  }

  return { atleastOne: true };
};

Then use directly in a group of checkboxes

// form component
<cr-input placeholder="Colors" error="At least one color" >
    <div formGroupName="colors" crinput validator="atleastOne">
      <label>
        <input type="checkbox" name="colors" id="color1" formControlName="red">
        Red
      </label> 
      <br>
      <label>
        <input type="checkbox" name="colors" id="color2" formControlName="black">
        Black
      </label> <br>
      <label>
        <input type="checkbox" name="colors" id="color3" formControlName="green">
        Green
      </label> <br>
    </div>
</cr-input>

That's enough.

Styling

In order to fine tune styling without making assumptions about the project style, nor using too smart CSS selectors, let's go back to few elements and dig deeper. Last episode. 😴

Did you speak up today?

References

StackBlitz project

Angular form field types

Ayyash — Mon, 13 Jan 2025 10:00:00 +0000

Today we are going to dig into validating all field types. We begin with the simpler ones: the string-based ones:

Email, tel, and text, are the easy ones; nothing that needs extra care
Textarea: This is like text input. It may need extra styling.
URL: This is not handled by Angular, so we can use a pattern matcher.
Number: The browser number field is powerful enough to prevent non-numeric values, but we can still use a pattern matcher for more control.

Other types are:

Select box: The only generic validation needed is required
Checkboxes and radio buttons: The most obvious validation is "at least one is selected"
Hidden fields: These are like text fields but need styling.

Textarea

This one is straightforward, the common validation is minimum and maximum number of characters, which is done via the native minlength and maxlength . This has already been covered. Looks like the style is also still holding.

Select box

The pain—or not! Using the first test: a list with “required” validation, the only missing thing we can style is the arrow. It begins with appearance: none. But that's a project-related choice.

UX tip: if it is required, select one by default.

Some high-security websites (like banking) mandate that the user makes a deliberate choice—whatever that means—but those were the exact words I was once told. In this case, an option with empty value acts as a null value and will trigger an invalid flag.

<cr-input placeholder="Operating system">
  <select crinput id="os" formControlName="os" [required]="true">
    <option value="">Select</option>
    <option value="1">Windows</option>
    <option value="2">Mac</option>
    <option value="3">Linux</option>
    <option value="4">Android</option>
  </select>
</cr-input>

This is how it looks when invalid

This actually worked better than I hoped for! Let’s move on.

Checkbox

For a single checkbox with required, functionally it works because it will be valid if true. But it looks awful. The label needs to be after the checkbox. Sucks doesn’t it?

// form component, the preferred syntax
<cr-input placeholder="Terms and conditions" error="Please accept">
  <input type="checkbox" name="accept" [required]="true" crinput id="accept" formControlName="accept">
</cr-input>
// ...
this.fg = this.fb.group({
    //...
    accept: [],
});

Won’t show you how it looks, we’ll fix all styles later. But it does work as expected.

Multiple checkboxes

There are a lot of ways to create a group of checkboxes with the same name. This article is not about that, but the end result I want to reach is a validation message that falls into place with other fields.

The four ways I know of are:

formGroupName with checkboxes
formArrayName with checkboxes
Checkboxes that update a validation state of the form
Checkboxes that update a hidden input that is part of the form

Here is a example of formGroupName that uses a cross-form validation function to set the state of the form as invalid. We make use of the invalidForm property to display the error.

// form componennt
template: `
  <cr-input placeholder="Colors" error="At least one color" [invalidForm]="fg.get('colors').hasError('atleastOne')">
    <div formGroupName="colors">
      <label>
        <input type="checkbox" name="colors" id="color1" formControlName="red">
        Red
      </label> <br>
      <label>
        <input type="checkbox" name="colors" id="color2" formControlName="black">
        Black
      </label> <br>
      <label>
        <input type="checkbox" name="colors" id="color3" formControlName="green">
        Green
      </label> <br>
    </div>
    <ng-container helptext>Choose at least one </ng-container>
  </cr-input>`

// ...
this.fg = this.fb.group({
  colors: this.fb.group({
    red: [],
    black: [],
    green: [],
  }, { validators: this.atleastOne})

});

atleastOne = (control: AbstractControl): ValidationErrors | null => {
  // if all controls are false, return error
  const values = Object.values(control.value);
  if (values.some(v => v === true)) {
    return null;
  }
  return { atleastOne: true };

};

The error shows when:
fg.get('colors').hasError('atleastOne')

It works, but it looks like the following. That, we’ll fix later.

We can also assign the directive to the formGroupName field, like this:

<cr-input placeholder="Colors" error="At least one color">
  // simply add crinput directive here
  <div formGroupName="colors" crinput>
    ...
  </div>
  <ng-container helptext>Choose at least one </ng-container>
</cr-input>

Keeping the validator as is, no need to use invalidForm. This validates nicely, and it looks as follows. A bit better.

Another way is to have the checkboxes separated in their own HTML element. This works as well if we want to display the bubble in a different location.

<cr-input placeholder="Colors" error="At least one color" [invalidForm]="fg.get('colors').hasError('atleastOne')">
    Select a color 
</cr-input>

<div formGroupName="colors">
    <label>
      <input type="checkbox" name="colors" id="color1" formControlName="red">
      Red
    </label> <br>
    <label>
      <input type="checkbox" name="colors" id="color2" formControlName="black">
      Black
    </label> <br>
    <label>
      <input type="checkbox" name="colors" id="color3" formControlName="green">
      Green
    </label> <br>
</div>

And it looks like this:

This is all possible because we kept it dead simple with the form feedback error class. We just need a bit more touch-ups, every project may have its own styling.

Radio button

As for radio buttons, they are bound to a single formControlName. The thing about radio buttons, is that the validation is almost always a cross-form validation. Best experience dictates that at least one should be checked by default. If none was checked by default, notice how by now we can use crinput directive on a normal HTML element, and get away with it. We use the invalidForm property to react to the invalid radio button.

<!-- add invalidForm to component -->
<cr-input placeholder="Gender" [invalidForm]="fg.get('gender').invalid">
  <!-- use crinpiut to div?! -->
  <div crinput>
    <input type="radio" name="gender" value="male" [required]="true"  id="male" formControlName="gender"> Male
    <input type="radio" name="gender" value="female" [required]="true" id="female" formControlName="gender"> Female
  </div>
</cr-input>

Looks as follows:

Let’s move on.

Hidden field

Hidden inputs simplify validation that would otherwise be challenging. They are mostly treated like text fields, with special styling. We will take care of that later.

Validation common functions

We created a patterns collection to reuse throughout our project, but we can also create common validation functions for reuse. Let's go through some common examples to build it up. Next episode, inshalla. 😴

Did you know that UNRWA is complicit in genocide?

Resources

Angular form field types - Sekrab Garage

Taming Angular forms. Today we are going to dig into validating all field types. We begin with the simpler ones: the string-based ones:<ul><li>Email, tel, and text, are the easy ones; nothing that needs extra care</li><li>.... Posted in Angular, Design

garage.sekrab.com

Angular form validation directive

Ayyash — Tue, 07 Jan 2025 10:05:00 +0000

The component we created thus far is enough to make the form invalid if submitted, and show the "required" balloon when the field is invalid. Following is other built in validations.

The final result is preferably an unobtrusive one like this:

<input crinput type="number" id="valvet" formControlName="valvet" [min]="3" [required]="true" />

Before we build the new crinput directive, the component itself can be enhanced.

We need to first add a location for the help text, and some new CSS. And a custom error property.

The error message belongs to our custom component but needs to be flexible and can be overwritten
The help text belongs to the project, don't even think about automating it
From user experience side, I believe stating the rule up front, then keeping the error message short is the best way to fill the form efficiently.

In our final HTML, this is where we want to get:

<!-- form template-->
<cr-input placeholder="Mars" error="Too small">
  <input crinput type="number" id="mars" formControlName="mars" [min]="2" />
  <ng-container helptext>Minimum of 2</ng-container>
</cr-input>

To reflect this in our input component, we use a new content selector

<!-- input.partial -->
<div class="{{ cssPrefix }}-field">
  <label class="cr-label" for="{{for}}">{{ placeholder }}</label>
  <ng-content></ng-content>
  <span class="cr-required"></span>
  <span class="cr-feedback">{{ error }}</span>
  <span class="cr-help">
    <!-- second content projection -->
    <ng-content select="[helptext]"></ng-content>
  </span>
</div>

And the CSS

.cr-field {
  /* ... */

  .cr-help {
    color: var(--sh-text-light, #959595);
    font-size: 90%;
    display: block;
    margin-block-start: var(--sh-halfspace, 0.8rem);
    text-align: end;
  }
  /* if there is nothing, hide it */
  .cr-help:empty {
    display: none;
  }
}

And finally the error message. That can be set as an input:

// input.partial
export class CrInputPartial implements AfterContentInit {
  // ...
  @Input() error: string;
}

Directive

The directive should implement Validator, the event to handle is

validate(control: AbstractControl): ValidationErrors | null

What we want to do is automate the error message based on the validation rule added, without canceling the validation. We need to provide the NG_VALIDATORS token to be able to implement Validator

// new lib/input/input.directive.ts

@Directive({
    selector: '[crinput]',
    // the "multi" allows the native validation to kick in first
    providers: [{provide: NG_VALIDATORS, multi: true, useExisting: InputDirective}]
})
export class InputDirective implements Validator {
    constructor() {}
    validate(control: AbstractControl): ValidationErrors | null {
    // to be implemented
    // set error text based on validation

    // then return null to continue with the native Angular validation
      return null;
    }
}

Back to our component, swap the ContentChild with the directive

// inut.partial

// ...
@ContentChild(InputDirective, { static: true }) inputDirective!: InputDirective;

Instead of having two content child definitions, one for the named element #crinput and one for the directive crinput, we can rely on the directive itself to get the element, and elevate it via a public property. Like this:

// input.directive
constructor(private el: ElementRef) {}

// the element is an HTML element of the input
public get element(): HTMLElement {
  return this.el.nativeElement;
};

In the input component

// input.component
export class CrInputPartial implements AfterContentInit {
  // we only need this
  @ContentChild(InputDirective, { static: true }) inputDirective!: InputDirective;

  ngAfterContentInit() {
    if (this.inputDirective) {
      const element = this.inputDirective.element;
      // if element exists:
      this.for = element.id;
      element.classList.add('cr-input');
      element.setAttribute('placeholder', this.placeholder);
    }
  }
}

So now we can remove the #crinput

<cr-input placeholder="Valvet">
  <input crinput type="text" id="valvet" formControlName="valvet" [required]="true" />
</cr-input>

The error message property

Let's start with the simple min validation. What we need is a way to read that property in the directive. One way to do that is to expose the min input.

// input.directive

// expose the min property
@Input() min?: number;

// create an error text property
private _error: string = 'Required';
public get errorText(): string {
    return this._error;
}
// ...
validate(control: AbstractControl): ValidationErrors | null {

    // if min exists
  if (this.min) {
    // change error message
    this._error = 'Too small';
  }
  // move on
  return null;
}

Then in the component

// input.component
template: `
  <div class="{{ cssPrefix }}-field">
    // ...
    <!-- use a new property errorText -->
    <span class="cr-feedback">{{ errorText }}</span>
  </div>
  `,

// keep error input
@Input() error: string;

// error text now is a combination
get errorText(): string {
  // get custom error or fall back to directive
  return this.error || this.inputDirective?.errorText;
}

The native validation kicks in afterwards. Let's add max input as well.

Edge case: min and max

If we test for both minimum and maximum at the same time, it won't quite work. We need to know which edge was the invalid edge.

<input crinput type="number" id="mars" formControlName="mars" [min]="2" [max]="5" />

In our validator, we need to validate using the native validation to see which edge was invalid.

 // input.directive

 // two inputs
@Input() min?: number;
@Input() max?: number;

// check which edge failed
if (this.min) {
  if (Validators.min(this.min)(control)) {
    this._error = 'Too small';
  }
}

// when max fails, change to message
if (this.max) {
  if (Validators.max(this.max)(control)) {
    this._error = 'Too large';
  }
}

There is one issue that blocked the process, and that is the errorText is not updating. The directive changes the value, but the component never picks up. Unless:

use ChangeDetectionStrategy.Default (nasty)
Join the Signal bandwagon (Finally, I have a proper use case!)

The errorText need to be a Signal.

// input.directive

@Input() min?: number;
@Input() max?: number;

// ...
// turn it into a signal
public errorText = signal('Required');
validate(control: AbstractControl): ValidationErrors | null {

  // when min fails, change to message
  if (this.min) {
    if (Validators.min(this.min)(control)) {
      this.errorText.set('Too small');
    }
  }

  // when max fails, change to message
  if (this.max) {
    if (Validators.max(this.max)(control)) {
      this.errorText.set('Too large');
    }
  }
  return null;
}

And the component now reads the signal:

// input.partial
get errorText(): string {
  // get custom error or fallback to directive error
  return this.error || this.inputDirective.errorText();
}

If it is also required, the message need to be reset. So reset to required on every validation. Also, we need to validate only when value is not null.

// directive
// slight adjustment to handle required as well
// always reset to required
this.errorText.set('Required');

// validate if value is not null
if (this.min && control.value) {
  if (Validators.min(this.min)(control)) {
    this.errorText.set('Too small');
  }
}

if (this.max && control.value) {
  if (Validators.max(this.max)(control)) {
    this.errorText.set('Too large');
  }
}

Reverse range

What if we want a truly custom validation, where the number should be outside range?

// directive
export class InputDirective implements OnInit, Validator {

  // simple array
  @Input() block?: [number, number];
    validate(control: AbstractControl): ValidationErrors | null {
      // ...
      if (this.block) {
        // its valid if the value is outside the block array
        if (control.value >= this.block[0] && control.value <= this.block[1]) {
          this.errorText.set('Invalid number');
          // one of the few times we need to return invalid
          return {
            block: true
          }
        }
      }
      return null;
  }
}

This is a sort of custom validation, so we need to return something, in this case block: true. You can complicate this further if you wish, but it's good enough for this project.

Length

It's quite similar to max and min:

// directive
@Input() minLength?: number;
@Input() maxLength?: number;

// in validate
if (this.minlength && control.value) {
  if (Validators.minLength(this.minlength)(control)) {
    this.errorText.set('Too short');
  }
}

if (this.maxlength && control.value) {
  if (Validators.maxLength(this.maxlength)(control)) {
    this.errorText.set('Too long');
  }
}

Pattern

Working backwards, the pattern is added as an attribute:

<!--html-->
<cr-input placeholder="Shortname">
  <input crinput type="text" id="shortname" formControlName="shortname"  pattern="[A-Za-z]{5}" />
  <ng-container helptext>Alphanumeric, 5 characters</ng-container>
</cr-input>

Then in our directive, we expose the pattern to change the error message:

// directive
@Input() pattern?: string;
validate(control: AbstractControl): ValidationErrors | null {
  // ...
  if(this.pattern) {
    this.errorText.set('Invalid format');
  }
  return null;
}

This might look enough. But this is our chance to reign our patterns. I would like my final result to look like this

<input crinput id="short-name" formControlName="phone" pattern="phone" />

The error message should be "Invalid short-name format", the specs of our new feature are:

'Phone' could be a look up that is constantly used, the message would be "invalid phone format"
Or it can be overwritten per project, the message would be "invalid format" or a custom error
Nice to have: allow the format to be added. Silliest way is: global const.
Or a simple rollback to default Angular pattern, the message would be "invalid format" or a custom error

First, we create a lookup for our phone pattern to be used globally.

Using pattern directly will fail, because it cannot be canceled if handled. And I will not dwell upon it much, overriding it or redefining the default behavior is not ideal. So we will stay away from the pattern attribute. We will create a new property: crpattern

// partial.directive

// new prop
@Input() crpattern?: string;

if(this.crpattern) {
  // the default
  this.errorText.set('Invalid format');
  // if pattern exists in our list (to be created), use validators
  let _pattern = InputPatterns.get(this.crpattern);
  if (_pattern) {
    this.errorText.set(`Invalid ${this.crpattern} format`);
      // now validate
    return Validators.pattern(_pattern)(control);
  }
}

We create a new file for the input patterns

// patterns.ts
export const InputPatterns = new Map<string, any>([
  ['phone', '[+\\d\\s]*'],
  ['password', '[\\S]{8,}']
]);

In our HTML, here are three scenarios that cover the requirements:

// form component

templtes: `
  <cr-input placeholder="Phone">
         <!-- A built-in phone format -->
    <input crinput type="text" id="phone" formControlName="phone" crpattern="phone" />
    <ng-container helptext>Alphabets and spaces</ng-container>
  </cr-input>
  <cr-input placeholder="Shortname">
      <!-- an adhoc new pattern -->
    <input crinput type="text" id="shortname" formControlName="shortname" crpattern="shortname" />
    <ng-container helptext>Alphanumeric, 5 characters</ng-container>
  </cr-input>
  <cr-input placeholder="Some pattern" error="Invalid koolaid format">
         <!-- native with a custom error -->
    <input crinput type="text" id="koolaid" formControlName="koolaid"  pattern="[1-9]{2,4}" />
    <ng-container helptext>Two to 4 numbers</ng-container>
  </cr-input>
  `
 // ...
 ngOnInit(): void {
  // add and adhoc pattern, this is forever
  InputPatterns.set('shortname', '[A-Za-z]{5}');

  // the form
  this.fg = this.fb.group({
    valvet: [''],
    mars: [1],
    buler: [],
    shortname: [],
    phone: [],
    koolaid: []
  });
// ...
}

This produces the following

So far so good. I'd rather use the silly way knowing that every project will have its own unique way to extend the formats. Personally, I would turn the patterns class into an abstract and override it locally.

Note about text

The ideal way is not to use the text in the directive directly but rather use a resources file. In my attempt to redefine localization in Angular, I came up with a Res class that reads the values off of a javascript file. But you can use your own translation solution to return the right message. My resources would look like this

"INVALID_phone_FORMAT": "Have you ever used a phone!",

Where shortname is the pattern key. The messages displayed in the directive would be:

this.errorText.set(Res.Get(INVALID_${this.crpattern}_FORMAT));

Email validation

It should be exactly similar to pattern, but according to the documentation, a sole attribute is enough: email. But because we need to map it, and read it, we should get into the habit of using an exact value. I choose boolean.

 <!--from component-->
 <cr-input placeholder="Email">
  <input crinput type="email" id="email" formControlName="email" [email]="true" />
  <ng-container helptext>Native email</ng-container>
</cr-input>

The validators

// input.directive
@Input() email?: boolean;

if(this.email) {
  this.errorText.set('Invalid email format');
}

Using the Angular native email validator is better, it keeps the email pattern up to date. But you will find yourself in situations where the pattern is too loose. For example email@example actually checks. In this case, use a custom crpattern instead.

Custom validation

This one has resolved itself. If we use a validation function, all we need now is to set a custom error message:

// form component
template: `
<cr-input placeholder="Custom name" error="Bob is not allowed">
  <input crinput type="text" id="koolaid" formControlName="name"  />
  <ng-container helptext>Not bob</ng-container>
</cr-input>
`

// inside class custom examle
forbiddenNameValidator = (nameRe: RegExp): ValidatorFn => {
  return (control: AbstractControl): ValidationErrors | null => {
    const forbidden = nameRe.test(control.value);
    return forbidden ? {forbiddenName: {value: control.value}} : null;
  };
}

// in form builder
name: ['',  this.forbiddenNameValidator(/bob/i)]

Cross form validation

In cross form validation things are not as clear. From user experience point of view, it isn't correct to place the error message out of context. There must be context. For example, password confirm validation, is a custom validation of the second input. Since we can have the function on the same page, the form value is available. So this has been covered. Here is the example in documentation.

// form
template: `
  <cr-input placeholder="Custom name" error="Bob is not allowed">
      <input crinput type="text" id="name" formControlName="name"  />
      <ng-container helptext>Not bob</ng-container>
    </cr-input>
    <cr-input placeholder="Role" error="Name cannot match role or audiences will be confused.">
      <input crinput type="text" id="role" formControlName="role"  />
    </cr-input>
`;

// in class
unambiguousRoleValidator = (control: AbstractControl): ValidationErrors | null => {
  // read the other control directly from form
  const name = this.fg?.get('name')?.value;
  const role = this.fg?.get('role')?.value; // same as control
  return name && role && name === role ? { unambiguousRole: true } : null;
};

name: [''],
role: ['', this.unambiguousRoleValidator],

The result looks like this

The only problem with this is that user needs to blur the Role field to validate again. The ugly way to fix it is watch changes on the first element, to update the second.

// form component
`<input crinput type="text" id="name" formControlName="name"
    (change)="checkRole()" />`

// ...

checkRole() {
  this.fg.get('role').updateValueAndValidity();
}

Form validation

Another way to catch cross-form validation is to validate the form itself. We still want the style to be attached to one control, but we want the trigger to be the form validation, instead of blur event validation. The simplest way is using CSS in combination to hasError

Going back to the above example, and changing the validator to be a form validator:

// form component

// add feedback somwhere, with a condition
template: `<div *ngIf="fg.hasError('unambiguousRole')" class="cr-form-feedback">An error here</div>`

this.fg = this.fb.group({
  //...
  name: ['', this.forbiddenNameValidator(/bob/i)],
  role: ['']

}, { validators: this.unambiguousRoleValidator });

Then in CSS, we just need to show it upon submission only (and add the colors and what not)

/* input.css */

.cr-form {
  .cr-form-feedback {
    display: none;
  }
  &.ng-submitted .cr-form-feedback {
    display: block;
  }
}

We can place that HTML element anywhere, if we place it inside a cr-input element, with an extra cr-feedback class, it would look like a normal contextual error.

<cr-input placeholder="Role" >
  <input crinput type="text" id="role" formControlName="role" [required]="true"  />
  <span *ngIf="fg.hasError('unambiguousRole')" class="cr-form-feedback cr-feedback">Name cannot match role or audiences will be confused.</span>
</cr-input>

Add a new property for cross field validation

We can now rewrite our input partial to cater for this with a new boolean property, let's call it invalidForm.

<cr-input placeholder="Role" error="Name cannot match role or audiences will be confused." [invalidForm]="fg.hasError('unambiguousRole')">
  <input crinput type="text" id="role" formControlName="role" [required]="true"  />
</cr-input>

In the library component

// input.partial

template: `
  // add to container compoennt
  <div class="{{ cssPrefix }}-field" [class.cr-invalid-form]="invalidForm">
    // and to feedback element
    <span class="cr-feedback" [class.cr-invalid-feedback]="invalidForm">{{ errorText }}</span>
  </div>
`,
@Input() invalidForm: boolean;

Now our css can accommodate the new cr-invalid-form, when the form is submitted, the cr-input should act as invalid because the invalidForm boolean is true when invalid.

/* input.css */

.ng-submitted {
  .cr-field {
    .cr-input.ng-invalid,
    /* add this selector */
    &.cr-invalid-form .cr-input {
      box-shadow: inset 0 0 0 1px var(--sh-red, #f31109);
      border-color: var(--sh-red, #f31109);
    }
    .cr-input.ng-invalid ~ .cr-feedback {
      display: block;
    }
    .cr-label:has(~ .cr-input.ng-invalid),
    /* and this selector */
    &.cr-invalid-form .cr-label {
      color: var(--sh-red, #f31109);
    }
  }
}
/* we can keep the .cr-form definiton for standalone feedback */

Changing the value of other fields no longer needs to be watched, as fg.hasError('unambiguousRole') is always up to date. Great.

Issue: Multiple error messages

The idea of having a custom error property is to overwrite the error messages in the component. But if there are multiple validations, the custom error will override them all. But we can bind the error message as follows:

[error]="fg.hasError('unambiguousRole') ? 'Name cannot match role or audiences will be confused.' : null"

If null, the required message takes over.

I personally have no problem with that, and I will not try to fix it to be a mutant. My simple user friendly solution is to change the message itself:

Required. And cannot match name to avoid confusion.

There. Problem solved.

Using the directive in other ways

Here is a scenario, a control of two fields, and the output result combined is what needs to be validated. Example: Month, and Year. Need to be in the future.

The idea is not to squeeze our control to handle that, but to have an output that follows the same design decisions. If we deal with them as separate fields, then it's just cross-form validation.

Ideally, the month and year controls, normal text controls, are wrapped inside a custom control that emits the value MMYY. Which is then assigned to a hidden input, that needs to be validated. This is easy and straight forward. Better than trying to squeeze in the validation in the non control. I like the fact that Angular turned validation to a simple custom function.

The only problem we will be facing is styling. Which we will be addressing later.

// form component

`<cr-input placeholder="Expiration" error="This is expired">
  <input type="hidden" crinput id="mmyy" pattern="[0-9]{4}" formControlName="mmyy" />
  // some component with MM and YY fields
  <cr-product-expiry (onValue)="expirationValue($event)"></cr-product-expiry>
</cr-input>`

//... in class
thisMonth: string = (new Date()).toISOString().substring(2, 7).replace('-', '');

futureValidator = (control: AbstractControl): ValidationErrors | null => {
  // if control MMYY in the future, return null
  const value = control.value;

  if (!value || +value > +this.thisMonth) {
    return null;
  }
  return {
    future: true
  };
};

expirationValue(value: { month: string, year: string; }) {
  // change form value to be mm then yy
  this.fg.get('mmyy').setValue(value.year + value.month);
}

// on init
this.fg = this.fb.group({
  //...
  mmyy: [null, this.futureValidator],
}

The result is looks like this. May be later we need to adapt the required asterisk for hidden fields.

The best experience

After years of working with different mindsets and different forms, I'd say the best experience in form validation is like this;

Do not validate first time, wait for first submission (unless it's an in place form, wait for blur)
Error messages, show all possible errors without breaking logic (Required, too large, or too small) but don't wait for a second input to show a different error.
Keep the error messages to the bare minimum, instead, depend on help text
Do not scroll up, toast

The last bit was a lesson I learnt the hard way. When there is a problem in form, toast that there are problems, then let user do their own scrolling up.

On submit, show your toast

submit() {
  if (this.fg.invalid) {
    this.toast.ShowError('INVALID_FORM');
  }
}

Want to create a toast control? Read about it in my Garage

Form types

Now that we validated the text input, let's move on to different types, and see what else we need to take care of. Besides the style. This should till next episode. 🥱

Did you know that Google is complicit in Gaza Genocide and Palestinian ethnic cleansing?

Resources

Alternative way to localize in Angular

Angular form validation directive - Sekrab Garage

Taming Angular forms. The component we created thus far is enough to make the form invalid if submitted, and show the “required” balloon when the field is invalid. Following is other built-in validations.The final result.... Posted in Angular, Design

garage.sekrab.com

Taming Angular Forms

Ayyash — Thu, 02 Jan 2025 11:38:00 +0000

Creating a form has always been a terrible task I keep till the end. And I usually just start with copying an existing form file. Today, I decided to do something about it. Here is a series to dig into Angular forms, in their simplest shape, and create reusable component to control validation.

I want to create a simple reusable solution for forms in Angular. A solution that is unobtrusive, and non-third-party reliant. The following is what I want to end up with:

Use native HTML input elements.
Validation rules should be kept to minimum
Keep the Angular form loose (do not reinvent the wheel)
Use attributes instead of Form builder (unobtrusive)
Keep form submission loose to allow as much flexibility
Minimum styling allowing full replacement.

The end result should look something like this:

In order to do that, we need to crack open the secrets of Angular forms. First, the HTML input basic form:

<input type="text" formControlName="name" [required]="true" />

The final solution can be found on StackBlitz

The series will cover the following topics:

Creating a component that relies on CSS only to display validation
Creating a validation directive to better control the error message
Listing the different input types and fine tune their validation
Putting together the most common validation functions, like Date, Password confirmation and Upload file validation

Opening the input box

Angular adds CSS classes and HTML attributes to the form field, upon interactions, as follows.

.ng-valid versus .ng-invalid reflects the validity at all times
.ng-pending used with asynchronous validation, between states
.ng-pristine versus .ng-dirty reflects whether the value changed, on keypress
.ng-untouched versus .ng-touched reflects the first state after blur, it will be touched after first blur
.ng-submitted is for the form element if it exists, after submission by firing the submit event

Angular mirrors native HTML classes, then disables it using novalidate, we will not enabled it because we don’t want to end up caring for two systems. Let’s dig in those classes. This is the simplest standalone form control:

// form page
@Component({
    // ...
  template: `<input type="text" [formControl]="valvet"  />`
})
export class FormComponent implements OnInit {
  valvet: FormControl;
  ngOnInit(): void {
    this.valvet = new FormControl('');
  }
}

Running, turns out the following

<input type="text" class="ng-untouched ng-pristine ng-valid" >

The flow is summarized as follows:

It begins with untouched and pristine
If blurred it becomes touched even if no value changed
If required is set, it starts with invalid, unless value is already set.
On keypress it receives dirty
Validity is updated whenever change occurs

The main thing to pay attention to: it becomes touched after first blur event, and not on focus.

Resetting using reset() returns everything to its initial state, except the value, it becomes empty.

Placing in a form element:

// form page
template: `
  <form [formGroup]="fg">
    <input type="text" formControlName="valvet" [required]="true"  />
    <button type="reset" (click)="reset()">Reset</button>
    <button type="submit">Submit</button> 
  </form>
   `
  // ...
  fg: FormGroup;

  ngOnInit(): void {
    this.fg = new FormGroup({
      valvet: new FormControl('')
    });
  }
  reset() {
    this.fg.reset();
  }

The form gets the same classes, and reflects the single input classes

/* Output */
<form novalidate="" class="ng-untouched ng-pristine ng-invalid">
  <input type="text" formcontrolname="valvet" class="ng-untouched ng-pristine ng-invalid" required>
  <button type="reset">Reset</button>
  <button type="submit" >Submit</button>
</form>

To continue with the flow:

It starts with untouched and pristine and valid
It reflects the state of at least one form field that is touched dirty or invalid
On submit button click, ng-submitted is added to the form classes.
Resetting does not take away the submitted state

Remember that by default the button type is submit, so we always need to be explicit about non submitting buttons. In this case, the reset button is of type reset

This is nice, we can control the validation style completely in CSS. The ideal behavior is: do not validate until submitted, there is nothing more annoying that validation nag.

Here is a quick example:

/* CSS to control the red border */
.cr-input {
  outline: 1px solid #ccc;
  border: 0;
}

/* when sourunded by ng-submitted */
.ng-submitted .cr-input.ng-invalid {
  outline: 1px solid red;
}

There might be times you want to handle it differently, by showing invalidity the minute it’s dirty.

/* a differnet way */
.cr-input {
  outline: 1px solid #ccc;
  border: 0;
}

/* when invalid and dirty */
.cr-input.ng-invalid.ng-dirty {
  outline: 1px solid red;
}

We can make an enhancement by removing the style on focus

/* garnish, on focus remove red border */
.cr-input:focus {
    outline: 1px solid #007bff;
}

We need to control the appearance of the required label, and the safest way is to wrap it with another element. The bare minimum of this new element is:

a label
an asterisk
a span with required text

The final result of the HTML should look like this

<!-- the targeted HTML -->
<div class="cr-field">
  <label class="cr-label" for="valvet">Valvet</label>
  <input type="text" id="valvet" class="cr-input" formControlName="valvet" [required]="true" />
  <span class="cr-required"></span>
  <span class="cr-feedback">Required</span>
</div>

The asterisk is a pseudo element. We can target the asterisk with the validity state

.cr-input ~ .cr-required {
  display: none;
  color: red;
  font-weight: bold;
  &:after {
      content: '*';
  }
}
.cr-input[required] ~ .cr-required {
  display: inline-block;
}

We can also target the parent-child relationship using the :has() operator. We will need that for the label, because we need to style the “previous sibling” according to state.

.cr-label {
  display: block;
  margin-block-end: 5px;
}
/* this is a new CSS feature */
.cr-label:has(~ .cr-input:focus-visible) {
  color: #007bff;
}

This looks nice. Last time I worked on this, I had to write a whole lot of code, now eliminated by two features:

:has() new selector
ng-submitted new state

Amazing!

Preparing for floating labels

One more pseudo class that can spice it up, is the :placeholder-shown selector. If the field is empty, the placeholder is showing. If field is focused, or the field is not empty, the placeholder is hidden. Let’s style this (this will come in handy when we create floating placeholders).

We don’t need the placeholder itself, because we will float in the label itself, later. So we make it transparent:

/* example styles to target placeholder */
.cr-input:placeholder-shown {
  outline: 1px solid green;
}
/* because we don't need the placholder */
.cr-input::placeholder {
  color: transparent;
}
.cr-label:has(~ .cr-input:placeholder-shown) {
  color: red;
}

But this means the placeholder value cannot be empty. We can place a “.” in it. Later we can automate this process when we create our component.

Finally the “required” feedback that appears when validated and form is submitted.

.cr-input ~ .cr-feedback {
  display: none;
  color: red;
  font-weight: bold;
}
.ng-submitted {
  .cr-input.ng-invalid {
    outline: 1px solid red;
  }
  .cr-input.ng-invalid ~ .cr-feedback {
    display: block;
  }
}

Nested styles are now native. Yippee!

The code can now be transferred into its own component. We probably need to add “id” for the label (naming it an id property is a bad choice, so we name it for). Let’s call it input.partial.ts. The native input field is content-projected.


// input.partial

@Component({
  selector: 'cr-input',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <div class="cr-field">
      <label class="cr-label" for="{{for}}">{{ placeholder }}</label>
      <!-- content projection -->
      <ng-content></ng-content>
      <span class="cr-required">*</span>
      <span class="cr-feedback">Required</span>
    </div>
    `,
})

export class CrInputPartial implements AfterContentInit {

  @ContentChild('crinput', { static: true, read: ElementRef }) inputElement!: ElementRef;
  @Input() placeholder: string;

  for!: string;
  ngAfterContentInit() {
    // get the id from the native element
    this.for = this.inputElement.nativeElement.id;
    // assign the default placeholder as a placeholder attribute
    this.inputElement.nativeElement.setAttribute('placeholder', this.placeholder);
  }

}

In the consuming component (let’s call it formComponent):

<!-- formComponent html template -->
<cr-input placeholder="Valvet">
  <input #crinput type="text" id="valvet" class="cr-input" formControlName="valvet" [required]="true" />
</cr-input>

The #crinput is necessary, but later we will create a directive to take care of other things and replace it.

Do we keep the styles contained within the component, or do we let the outside world define it? I’m torn.

I usually prefer to keep it outside, so that each project has its own styling.
For the past 5 or so years, I rarely touched the CSS

So to stay true to both, let’s add the CSS in the component, but allow an override of the parent class for further fine tuning.

// input.partial
@Component({
  // ...
  styleUrl: 'input.css',
  // do not encapsulate
  encapsulation: ViewEncapsulation.None,
  // added cssPrefix
  template: `
    <div class="{{ cssPrefix }}-field">
      <label class="cr-label" for="{{for}}">{{ placeholder }}</label>
      <ng-content></ng-content>
      <span class="cr-required">*</span>
      <span class="cr-feedback">Required</span>
    </div>
    `,
})
export class CrInputPartial implements AfterContentInit {
    //...
    // make the cssPrefix an optional input
  @Input() cssPrefix: string = 'cr';

  ngAfterContentInit() {
      // push the class to the input
    this.inputElement?.nativeElement.classList.add(`cr-input`);
  }
}

The CSS is going to be a floating labels style, we will use CSS vars with a fallback, and we will not include the width, because width is defined in the consumer. Every project has its own story.

The CSS:( --sh stands for shut)

/* input.css */

.cr-field {
  position: relative;
  display: block;
  margin-block-end: var(--sh-doublespace, 3.2rem);
  margin-block-start: var(--sh-halfspace, 0.8rem);
  .cr-input {
    border: 1px solid var(--sh-grey, #999999);
    border-radius: var(--sh-radius, 3px);
    appearance: none; /* I don't think this is necessary */
    outline: none;
    padding: var(--sh-halfspace, 0.8rem);
    box-shadow: 0 2px 5px 0 var(--sh-grey-light, #f3f3f3cc);

    background-color: var(--sh-white, #ffffff);
    caret-color: var(--sh-linkcolor, #0c00b4);
    &:focus-visible {
        outline: none;
        border-color: var(--sh-linkcolor, #0c00b4);
        box-shadow: 0 0 0 1px var(--sh-linkcolor, #0c00b4);
    }
    /* nice to have, hide asterisk when input is focused */
    &:focus-visible ~ .cr-required {
        display: none!important;
    }
    &::placeholder {
      color: transparent!important;
    }

  }
  .cr-input ~ .cr-required {
    display: none;
    position: absolute;
    inset-inline-end: var(--sh-halfspace, 0.8rem);
    inset-block-start: 0;
    z-index: 2;
    &:after {
        display: block;
        content: '*';
        font-size: 1.6rem;
        font-weight: var(--sh-font-weight-bold, 700);
        line-height: 1.5;
        color: var(--sh-red, #f31109);
    }

  }
  .cr-input[required] ~ .cr-required {
    display: inline-block;
  }

  .cr-feedback {
    background-color: var(--sh-red, #f31109);
    color: var(--sh-white, #ffffff);
    margin-inline-start: 1rem;
    margin-block-start: calc(-1 * var(--sh-halfspace, 1.6rem));
    width: fit-content;
    float: inline-start;
    z-index: 100;
    position: relative;
    border-radius: var(--sh-radius, 3px);
    padding-inline: var(--sh-halfspace, 0.8rem);
    padding-block: calc(var(--sh-halfspace, 0.8rem) / 2);
    white-space: nowrap;
    display: none;
    font-size: 85%;
  }

  /* floating label */
  .cr-label {
    position: absolute;
    inset-block-start: var(--sh-halfspace, 0.8rem);
    inset-inline-start: 9px;
    padding: 0 3px;
    color: var(--sh-text-light, #959595);
    cursor: auto;
    transform-origin: left;
    transition: transform 0.3s;
    transform: translateY(-100%) scale(0.8);
    /* a touch to hide the border behind the floating label */
    background-image: linear-gradient(0deg, var(--sh-white, #ffffff) 62%, transparent 62%);
  }
  /* when input is empty */
  .cr-label:has(~ .cr-input:placeholder-shown) {
    transform: none;
  }
  /* when input is focused */
  .cr-label:has(~ .cr-input:focus-visible) {
    transform: translateY(-100%) scale(0.8);
  }
}

/* when sourunded by ng-submitted */
.ng-submitted {
  .cr-field {

    .cr-input.ng-invalid {
      box-shadow: inset 0 0 0 1px var(--sh-red, #f31109);
      border-color: var(--sh-red, #f31109);
    }
    .cr-input.ng-invalid ~ .cr-feedback {
      display: block;
    }
    .cr-label:has(~ .cr-input.ng-invalid) {
      color: var(--sh-red, #f31109);
    }
  }
}

The form itself is simple:

this.fg = this.fb.group({
  valvet: [''],
  mars: ['']
});

The initial state of this component is coming together, find it on StackBlitz.

Next.

Validation

We now know how to make it required, the above was enough to make the form invalid if submitted, and show the required balloon. Let’s see other built in validations. Next episode. 🥱

Did you see how useless touching an input was?

Resources

Using CSS to validate Angular reactive form - Sekrab Garage

Taming Angular Forms. I want to create a simple reusable solution for forms in Angular. A solution that is unobtrusive, and non-third-party reliant. The following is what I want to end up with:<ul><li>Use native HTML input.... Posted in Angular, Design

garage.sekrab.com

DEV Community: Ayyash

When third party needs a forth party it becomes a crowd

Bootstrapping

Lifecycle hooks

Nutshells

Documentation

Out of the box solutions

Potentials

Side note about AI completion

HTML sanitizing

Server Side Rendering and support

Intent

Server side rendering and hydration

Request and Response

Serving and building

API server support

Vite

Multilingual support

Next

When simple is stupid

Angular vs Svelte

Error handling

Svelte Error handling

Angular error handling

Forms

Form directive and validation

Bindable values

Routing

Reuse strategy

Preloading

Navigation events

Reroute Hook

Projection

Resources

Frontender in the middle

Angular vs Svelte

Dependency injection

Http Client

Interception

Http Context

Reactivity

Template imports

Error handling

Putting Angular Fire Firestore library to use - II

Mapping data

Create document

The curious case of Firestore syntax

Update document

Delete document

Querying responsibly

Timestamp

Firestore Lite

Interception

Resources

Related posts

Putting Angular Fire Firestore library to use - I

Setup

The Firestore reference

Note about referencing the right SDK

Get data

Getting the document id

Get by document ID

Query

Cold observables

Mapping data

References:

Angular Firebase Authentication Update: v.19

Providers

APP_INITIALIZER token

Validation style final tweaks

Checkbox

Testing the edges

Testing another edge case: Nice looking checkbox

Hidden fields

Auto-filled fields

Bonus: standalone imports

Conclusion

Resources

Angular validation common functions

Date