DEV Community: Ryan Hoffman

GSchema - A schematics engine written in go

Ryan Hoffman — Mon, 01 May 2023 16:32:15 +0000

https://www.npmjs.com/package/gschema

A schematics engine written in go in-order to innovate the schematics niche and increase development speed.

Install

npm install -D hopemanryan/gschema

How to use

Templates

Templates files must end with a __templ__ suffix
The regex pattern for dynamic content is: <% file_name =%> (in the context file_name is a variable)
You can add dynamic variables to file names <% file_name =%>Component.ts__templ__
Javascript functions are supported (see more down bellow)

#### Example

 const <% toUpperCase(file_name) =%>Component = () => {

}


const <% file_name =%>Component = () => {

}

Basic usage

node ./node_modules/gschema/gschema.js -file_name=demo1 -read_dir=./abc

JS functions

Schematics are more popular in the Javascript community. There for we have added support to add a JS file that will have functions which can be used in the template files

// gschema.js
function toUpperCase (val) {
    return val.toUpperCase();
}

This will load the function and the engine sees toUpperCase it will run the function with variable value as the argument toUpperCase('demo1') and return the value DEMO1

Shorthands

gschema.config.json is the config file that can be used for shorthands configuration

{
    "shorthands": {
        "demo": {
            "templatePath": "./abc"
        }
    }
}

node ./node_modules/gschema/gschema -file_name=demo1 -s=demo

The engine will use the predefined config, this allows true re-usability of templates

How To Use Mock Data Without Changing Internal Logic

Ryan Hoffman — Thu, 26 Jan 2023 12:00:00 +0000

In every job and every company, that day always comes where you find that you…actually need to do some work. And by that, I mean finding new innovative solutions to tasks and projects instead of going with the tried-and-true methods. Recently, my team, of full stack developers were tasked with building a webview app to support our live debugging IDE plugin. This would allow us to align the user experience with our pre-existing web app. Using the IDE plugin’s UI framework meant we would need to rewrite a lot of the code, which would also result in a very different user experience due to the differences between frameworks and a lot of engineering time which means a lot of money.

Obviously, that’s not the ideal choice. So we decided to take a bit of a different approach. You know, one that would make our lives easier and help us create a better product, faster, and maintain the high-level of user experience our customers expect.

A New Approach

In order to be aligned with our web application we decided to shift from using our plugin’s UI system (Swing in Jetbrains case) and use a modern frontend framework (React) which is much better at rendering – and more importantly, re-rendering – a lot of UI elements. The decision also brought about many smiles in our team as it was easier for us to develop due to us having more experience developing with Javascript than Java Swing. Our goal and mindset was to develop quickly, efficiently, and with as little friction as possible and not be coupled to the plugin by having to rerun the plugin with every change to the UI code.

With that goal in mind, well..we all know the saying of ‘people plan…’, right? As with every good new feature or product, we encountered problems which were unrelated to the webview but impacted development efficiency.

Speeding Up Code Development

In order to overcome these issues we chose to take an unconventional route of building mock data responses. These are predefined data sets that mimic the data we would have received from other services, while overriding native communication functions such as “fetch”. This solution dealt with many of the issues we wanted to tackle, such as keeping our code clean and allowing each part of the whole system to be developed separately.

Keeping services decoupled from one another is a best practice in backend development when working with microservices.It allows complete autonomy of development and deployment per service, which means that as long as we are backwards compatible it is possible to continue to advance and deploy our UI without taking into account the missing correspondent changes from the plugin (other services). When using mock data, it’s common to succumb to the pull of changing your code so as to be aware that mock responses are being used. However, this dirties up the code and can cause future bugs.

For example, the code block below demonstrates specifically how the code is aware of the usage of mock responses. We indicated that if we are in a development environment it should return mock data.

if (env === "development"){
return  {...mockData} <-- local response
} else {
 return fetch(...)
}

In contrast to what we see in the code block above, what we would like to achieve is the ability to return mock data and not make our internal logic aware of the fact that it is getting mock data.

So What Do We Do?

Using mock responses has been a great tool for me as it has allowed me to continue developing my features or fixing bugs without being dependent on the development and prioritization of others. For example, what might be a major issue on my end could be a minor issue on their end and vice versa. Specifically at Rookout, we develop the IDE plugin at the same time as the Web UI, which acts as an individual service that is dependent on data received from the plugin. With the mock responses I don’t have to wait for development on the plugin to finish before I can start working on my own tasks.

The top two options that I personally employ when I need to use mock responses are:

Creating a local web server that will take all requests and return the data as if it was the missing agent. While this solution works great, it requires some setup and for the developer to have a certain level of knowledge (basic as it may be) in backend development.

If the logic is kept untouched it will always point to whatever env.backendUrl stores, which by environment will point to your local machine or production machine.

// dev: localhost://...
// prod: https://...
const url = env.backendUrl
return fetch(url

The second option – and my main focus for this article – is overriding the original behavior of the api we are looking to use (i.e fetch).

In modern frameworks we have a main.js/ts file which handles the initial load of our web application. This is the area where we can do our magic.

window.fetch = function (request) {
   return new Promise(resolve => {
     if(typeof request === "string") {
       return resolve({
         isGetMethod: true
       })
     } else {
       const response  = {
         isGetMethod: request.method === "GET",
       }
       if(request.method === "POST") {
           response["body"] = async () => {
             return {
               ...mockData
             }
           }
       }
       return resolve(response)
     }

   })
 }

const root = ReactDOM.createRoot(
 document.getElementById('root') as HTMLElement
);

root.render(
 <StrictMode>
   <App />
 </StrictMode>
);

In the code block before the app loads, we override the fetch api with our custom behavior. Any fetch done in our react app will get to our new implementation instead of the original fetch api.

An explanation of what the demo above does:

If the request’s method is “GET”, return {isGetMethod: true}
If the method is “POST” , return as an async function (implementation of res.body()) which returns the mock data we want to receive.

In order to show the result let’s take a look at the simple component:

export const Comp = () => {

useEffect(() => {
 fetch({
   url: "https://jsonplaceholder.typicode.com/todos/1",
   method: 'GET'
 }).then(console.log) <-- example of response with get

 fetch({
   url: "https://jsonplaceholder.typicode.com/todos",
   method: 'POST',
   body: {
     "title": "demo"
   }
 }).then(console.log) <-- example of response with post

 fetch({
   url: "https://jsonplaceholder.typicode.com/todos",
   method: 'POST',
   body: {
     "title": "demo"
   }
 }).then(async (res) => {
   console.log(await res.body()) <-- example of parsing body response
 })

}, [])


return (<div>A Comp</div>)
}

The component sends requests to “production” endpoints, but the response is dealt with locally. Amazingly, no internal code change was made and reduced probability to produce new bugs while deploying to production.

WAIT A MOMENT!

A change in main.js/ts was made! How do we deal with it?

Popular Frontend frameworks as React/Angular (and NX as a mono-repo manager) supports using different “main” files when using different configurations for building and serving our application, and thus we can make two “main” files:

main.js/ts
main-mock.js/ts

"mock": {
         "extractLicenses": false,
         "optimization": false,
         "sourceMap": true,
         "vendorChunk": true,
         "main": "apps/demo/src/main-mock.tsx",
         "fileReplacements": [
           {
             "replace": "apps/demo/src/environments/environment.ts",
             "with": "apps/demo/src/environments/environment.mock.ts"
           },

         ]
       },

The default is our main.js/ts (kept untouched) and it is our main-mock for when we build with the mock configuration.

This will provide two big benefits:

The original main file is kept untouched.
Code added for mock responses will not be bundled when building production configurations and as a result will not affect customer facing bundle size (will not impact performance).

Why is all this work worth it?

Simply put? It’s a game-changer for quick and efficient development.

When we want as a team to develop multiple features simultaneously, we need the ability to work as independently as possible from one another but to also be aware of the fact that in production all parts will be – and are – connected. Each of us affects the other, whether we see it or not.

Using mock data responses by overriding our communication functions (such as fetch) allows us to keep our code unaware of the fact that its being fed mock data and will allow us to develop new features quickly and safely while also giving us the opportunity to debug issues that might occur.

A happy bonus to this pattern is that usually, as a result of the separation of concerns in development, the code we write is much less error prone and can handle almost any data thrown at it. Therefore, it is also much easier to replicate edge cases and create unique handlers for such cases. And if a bug does somehow occur, well that’s what Rookout is for: production debugging, so that you can see what caused the bug and replicate it with mock responses.

The idea of parallel work is something we all wish to achieve as a team, but very hard to implement. By using mock data, we are now one step closer to achieving it.

Give it a try. Happy coding 😉

Who is the boss of your components?

Ryan Hoffman — Mon, 30 Nov 2020 19:25:27 +0000

I have been working with Angular since about version 2.0.0 , from small applications, IOS/Android ones, to large scale enterprise level applications. I love Angular and that's why I always justified using it, but it wasn't since lately working with an abnormally large team, where I deeply understood the implications of bad Angular and smart Angular coding.

Architecture wise all my apps probably look the same, thanks to Angular's opinionated , very... , way of work, which forces us, it's users to code in a very specific way. So whats the difference ? why did I my team suffer ? At some point I got it, who should take more responsibilities ? the employee or the boss ?

Who's is the boss of your component ?

lets say we have a component the shows the client's name

@Component({
  selector: 'ng-client-name',
  templateUrl: './client-name.component.html',
  styleUrls: ['./client-name.component.css']
})
export class ClientNameComponent implements OnInit {

  @Input() name: string
  constructor() { }

  ngOnInit(): void {
  }

}

Who decides on the fallback ? the component? or its user ?
well it depends, but lets see this simple example through

<ng-client-name [name]="clientName || 'Creg'" ></ng-client-name>

In the above example, the parent component is incharge of the fallback, if no clientName, show "Creg" Instead.
ClientNameComponent will always have a value.

But what about the code block below ?

  @Input() name: string = "Creg"

In this use case, in contrary to the other code block the component keeps it self safe, no error could occur since the possible issue is contained and dealt with inside it self.

This simplified example, that we could all probably write a quick fix for all use cases in about 2-3 minutes, shows a deep problem while working with a large team. Who is the boss? Me making the component, or the the other person who uses it ?

Do not try to think like your colleagues, won't work, and making everything super compatible to everything and everyone is even worse.

While building a shared Angular library I had to build components to be used on 3 different apps with different functionality, so who is the boss of the logic ?
the answer? the component, but we fake it so they think its the parent. Confused? let me explain.

@Component({
  selector: 'ng-client-name',
  template: `
<div>
     <span>{{name}}</span>
     <input (change)="change($event)"/>

 </div>
`,
  styleUrls: ['./client-name.component.css']
})
export class ClientNameComponent implements OnInit {

  @Input() name: string;
  @Output() onChange: EventEmitter<string> = new EventEmitter<string>();
  constructor() { }

  ngOnInit(): void {
  }

  change($event: any): void {
    this.onChange.emit($event.target.value);
  }

}

From the code block above we see that the component is the boss of the internal logic, the component decides when to update the parent of the change. but the parent is in-charge on what to do with the change.

<ng-client-name [name]="name" (onChange)="updateName($event)"> </ng-client-name>

This ideal may seem a little annoying to work with at first, since there is a lot of code to be written on both sides of the component, but this forces us to do a couple of things:

Deeply understand the scope of the functionality of each component
Automatically each component gets a higher level of dynamic ability.
When scope is clear, the behaviour on all platforms is small but controlled and contained .
More maintainable .

Creating shareable components is very common, usually we do simple things, like buttons, checkboxes, essentially one for one, one entry point and one exit point, and the whole logic is done by the parent, or complete blackboxes which are completely independent. this happens in order to create easier to transfer components, but in hindsight it creates a lot of duplication code or no customisability , since each user of the component needs to deal with its edge cases... and if we wrap it with our own component, than whats the point.

When working with a team, your goal is the success of the team. the team's success > product's success > your success.

Hopefully this article will help you make better components and be better team player.

For any questions feel free to PM me or leave a comment below.

ps.
This is obviously an opinion and a success story for my self I wanted to share, no religious beliefs here :)
Stay safe

Angular - lazy load single component

Ryan Hoffman — Thu, 24 Sep 2020 11:11:13 +0000

Building an Angular app with scale in mind is tricky. We are already accustomed to lazy loading routes and by that decreasing bundle size and decreasing initial load times and letting the user interact with our web/app quicker.
With in time our Web-App will have to do more and more, which will effect the page load time and this can become extremely noticeable when building very large and dynamic forms with dynamic changing parts.
If we could just load the components that are needed in the current form and not all of them at once, load time will decrease and also we haven't exposed unnecessary code to the client (Its still there in the js files, just the UI doesn't render it).

So now that we have gone through with the examples and some benefits how is this done? Angular is primary a very closed framework, no easy workarounds which ensures the validity of the framework and to ensure build quality at all times.
But there is a still a way, an Angular way even.

@Component({
    selector: 'app-parentMock',
    template: ``,

  })
export  class ParentComponent implements OnInit {
    constructor(
        private componentFactoryResolver: ComponentFactoryResolver,
    ) {}
}

CompoentFactoryResolver is the a class Angular exports in order to create components in run time. It has some quirky behaviors but lets continue with the example.


@Component({
    selector: 'app-parentMock',
    template: ``,

  })
export  class ParentComponent implements OnInit {

    demoObj = {
        demo: {
            load: () => import('../mock/mock.component')
        }
    }

    constructor(
        private componentFactoryResolver: ComponentFactoryResolver,
    ) {}

    async ngOnInit(): Promise<void> {
        await this.loadComponent();
      }


      async loadComponent() {
          /** This saves loads the raw un-angular data into the loadFile */ 
          const loadFile: {default: any}  = await this.demoObj.demo.load(); 

      }

}

We have the object with the relative path of the component we want to load and as you can see in the snippet above there is the type {default: any} of the variable loadFile. This will not have a value at first. In order to do so in the component you are lazy loading at the bottom of the component (outside of it though) add :

This is extremely important

export default MockComponent

Now comes the tricky part which I will explain more on


@Component({
    selector: 'app-parentMock',
    template: `
        <ng-template #lazyTab></ng-template>
    `,

  })
export  class ParentComponent implements OnInit {
    /** The html element we will be loading the component into */
    @ViewChild('lazyTab', {static: true}) lazyTab: ViewContainerRef;

    lazyLoadedCompoent: ComponentRef<any>;


    demoObj = {
        demo: {
            load: () => import('../mock/mock.component')
        }
    }

    constructor(
        private componentFactoryResolver: ComponentFactoryResolver,
        private injector: Injector,

    ) {}

    async ngOnInit(): Promise<void> {
        await this.loadComponent();
      }


      async loadComponent() {
          /** This saves loads the raw un-angular data into the loadFile */ 
          const loadFile: {default: any}  = await this.demoObj.demo.load(); 

          /** This loads the Angular component into the the varibale for later use */
          const actualComponent = this.componentFactoryResolver.resolveComponentFactory(loadFile.default);


          const viewRef: ViewContainerRef = this.lazyTab.viewContainerRef;

          /** Clear any existing html inside of of the ng-container */
          viewRef.clear()

          /** We both insert the component in to the ref and save it for later use
           * 
           *  Adding the injector is to let it load other requiered things like services and other dependecies it might have
           */
          this.lazyLoadedCompoent = viewRef.createComponent<any>(actualComponent, null, this.injector)

      }

}

Lets go over that last snippet

lazyTab(In the html) : This is template reference variable which we will use in order to tell angular where to insert that lazyLoaded component

@ViewChild('lazyTab' .... : Here we giving access to typescript to work with the template reference variable

loadFile: a variable created to save the created RAW component

actualComponent : The Angular component that we have created in runtime

Now that we have our component loaded we might want to add INPUTs or OUTPUTs to the component to keep it in sync with our entire app.
Before continuing I feel the need to talk about Angular change detection and how NgZone is the main black magic in all of Angular's Magic.
NgZone is what makes the app react to changes and update it self. It works in a way matter of scopes. and if you are working outside of the Angular scope, your changes won't be detected and therefor no UI update.



@Component({
    selector: 'app-parentMock',
    template: `
        <ng-template #lazyTab></ng-template>
    `,

  })
export  class ParentComponent implements OnInit {
    /** The html element we will be loading the component into */
    @ViewChild('lazyTab', {static: true}) lazyTab: ViewContainerRef;

    lazyLoadedCompoent: ComponentRef<any>;


    demoObj = {
        demo: {
            load: () => import('../mock/mock.component')
        }
    }

    constructor(
        private componentFactoryResolver: ComponentFactoryResolver,
        private injector: Injector,
        private zone: NgZone,
    ) {}

    async ngOnInit(): Promise<void> {
        await this.loadComponent();
      }


      async loadComponent() {
          /** This saves loads the raw un-angular data into the loadFile */ 
          const loadFile: {default: any}  = await this.demoObj.demo.load(); 

          /** This loads the Angular component into the the varibale for later use */
          const actualComponent = this.componentFactoryResolver.resolveComponentFactory(loadFile.default);

          const viewRef: ViewContainerRef = this.lazyTab.viewContainerRef;

          /** Clear any existing html inside of of the ng-container */
          viewRef.clear()

          /** We both insert the component in to the ref and save it for later use
           * 
           *  Adding the injector is to let it load other requiered things like services and other dependecies it might have
           */
          this.lazyLoadedCompoent = viewRef.createComponent<any>(actualComponent, null, this.injector)

          /** To ensure the next changes are kept inside the Angular Zone Scope */
          this.zone.run(() => {
              this.lazyLoadedCompoent.instance['any-INPUT-you want'] = 'Lazy Loaded Component'
          })
      }
}

the zone.run... will make it so that the changes in side the lazyLoaded component will be detectedrun ngOnChanges when you set/reset those INPUTs.

So now how about OUTPUTS ? well OUTPUTS are functions we pass on so how will that be done ?


@Component({
    selector: 'app-parentMock',
    template: `
        <ng-template #lazyTab></ng-template>
    `,

  })
export  class ParentComponent implements OnInit {
    /** The html element we will be loading the component into */
    @ViewChild('lazyTab', {static: true}) lazyTab: ViewContainerRef;

    lazyLoadedCompoent: ComponentRef<any>;


    demoObj = {
        demo: {
            load: () => import('../mock/mock.component')
        }
    }

    constructor(
        private componentFactoryResolver: ComponentFactoryResolver,
        private injector: Injector,
        private zone: NgZone,
    ) {}

    async ngOnInit(): Promise<void> {
        await this.loadComponent();
      }


      async loadComponent() {
          /** This saves loads the raw un-angular data into the loadFile */ 
          const loadFile: {default: any}  = await this.demoObj.demo.load(); 

          /** This loads the Angular component into the the varibale for later use */
          const actualComponent = this.componentFactoryResolver.resolveComponentFactory(loadFile.default);


          const viewRef: ViewContainerRef = this.lazyTab.viewContainerRef;

          /** Clear any existing html inside of of the ng-container */
          viewRef.clear()

          /** We both insert the component in to the ref and save it for later use
           * 
           *  Adding the injector is to let it load other requiered things like services and other dependecies it might have
           */
          this.lazyLoadedCompoent = viewRef.createComponent<any>(actualComponent, null, this.injector)

          /** To ensure the next changes are kept inside the Angular Zone Scope */
          this.zone.run(() => {
            /** INPUT */  
            this.lazyLoadedCompoent.instance['any-INPUT-you want'] = 'Lazy Loaded Component'

            /**  OUTPUT */
            this.lazyLoadedCompoent.instance['an-OUTPUT-type-of-new-Emitter'].subscribe((dataPassedByTheEmit: any) => {
                console.log(dataPassedByTheEmit);
                /** Do what ever you want wit it */
            })
        })
      }
}

So the OUTPUT is of type Emitter which means we can subscribe to it and get the data which is emitted from the lazyLoaded component.

This is amazing , we have a fully living component that was loaded in runtime by the app.

Lets talk about the downsides first

This requires a lot of overhead and ability write maintainable code.
Doing this for a number of components that can change will require more overhead and a way to keep things updated when the user changes between components
This is not a very Angular way of doing things
Components are still loaded in the module.
Bundle size is not decreased

upsides:

Decrease load time on extremely large forms or pages.
Ability to load a component in reference to the type of user that is signed in
When you want to have the option to load components from a server
running A/B testing
Super cool idea that has been tested in production for a very large scale application.

Hope you enjoyed this small tutorial.
For any questions or comments feel free to comment and I will be happy to reply

Hamster(Alpha) - Manage your JS projects in once place

Ryan Hoffman — Sun, 06 Sep 2020 12:00:41 +0000

Hamster is a small app that you can use to run, manage and group together in once place.
To ensure safety, this app does not require any internet or any db installed on user's system. All is done local.

I have used Angular and Node as the primary tools for this electron app.

Hamster is free for all to use/fork/contribute.
More than happy to hear review/opinions and critics

Github: https://github.com/hopemanryan/hamster
Template made product page : https://hamster-app.com/

Deno - A continuation of the JavaScript framework fad?

Ryan Hoffman — Sat, 23 May 2020 09:00:53 +0000

TL:DR - Deno must change syntax in order for it to succeed, attempting to keep the original nodes target audience may cause so many issues in the future.

Ah Deno, You have been spammed all over my feed in every social media possible. The new kid on the block came with a very cool toy everyone wants to play with. But is it really a cool toy ? or the same toy with a cool new paint on it?
Assuming most Node.js developers are well annoyed with the fad of Javascript UI SPA/SSR frameworks (For SEO Reasons: Angular/React/Vue ) and we all had our conversations and arguments of which one is better and why.

This Fad has been slowly been passed from the client to the Server side of JavaScript, Node.
With libraries like Nest/Curve-ball that essentially are a nice wrapper for an express/koa sever application. So what is different with Deno?
I won't go in detail about what is Deno, but I would like to talk about who is Deno, Ryan Dahl Is the original Node.js developer and maintainer for a while. He left the Node.js project and now he is back in attempt to fix all the issues he sees in Node.js today (ahem ahem promises).
So how do you fix something but keep the same target audience ? You keep the syntax…

Deno has its quirks but writing a small Deno app (since that's all that can be done at the moment) is Just like Node, and I mean JUST LIKE NODE.
I can already hear the "But you add async to for loops" comment. But that goes around the entire Idea of single responsibility, Let a single function deal with that, that already has the async () => {} and loop inside.
Deno is very young and has the potential to have a killer ideas. but for that to happen syntax must change, or at least adapt. And here is an example of what I mean:
Lets take Python's print command, which writes to the console (console.log() for JS ), We are all aware of that Print does, what arguments it takes and what to expect as an output. But if i create "Xython" (Just a joke, chill…. ) And say that Print() will look for a physical printer and print its arguments, As a user of the command you will be pretty shocked and confused as why a command so similar does something so different.
The Python example is extreme, but its passes the idea of what In my opinion is the initial flaw of Deno. If you keep the syntax and change under the hood this may cause a huge confusion in the community… and so many errors/issues if someone tries to convert his/her app to a Deno app.

A new coding language is a blessing. It creates diversity in the community and new options to create new or better things, but its a hard sell sometimes. Rust and Go are two perfect examples of this. Here to fix specific issues but it has a "steep" learning curve do to syntax learning which can be annoying at times, especially with JS developers(callbacks, Loosely typed, etc… ).

Javascript frameworks are "just the opposite" the syntax is different but under the hood its pretty similar (or at least the concepts are similar).

I would love to hear your thoughts about Deno on this aspect