DEV Community: adro.codes

Generate a Azure SAS token

adro.codes — Thu, 24 Nov 2022 22:43:16 +0000

After you've created a Shared Access Policy (SAP) you will need to generate the token to use when send API calls.

We can generate these ourselves, and luckily, Microsoft provides some code for us (see documentation above). Below is a small node script using this code to make life easy.

const crypto = require("crypto")

// In seconds - week
const EXPIRES_IN = 60*60*24*7;

function createSharedAccessToken(uri, saName, saKey) { 
    if (!uri || !saName || !saKey) { 
          throw "Missing required parameter"; 
    } 
    var encoded = encodeURIComponent(uri); 
    var now = new Date();
    var ttl = Math.round(now.getTime() / 1000) + EXPIRES_IN;
    var signature = encoded + '\n' + ttl; 
    var hash = crypto.createHmac('sha256', saKey).update(signature, 'utf8').digest('base64'); 
    return 'SharedAccessSignature sr=' + encoded + '&sig=' + encodeURIComponent(hash) + '&se=' + ttl + '&skn=' + saName; 
}

const uri = "" // Endpoint
const saName = "" // SAP Name
const saKey  = "" // Primary or Secondary Key

console.log(
    createSharedAccessToken(uri, saName, saKey)
);

From what I can tell, there isn't a max for the EXPIRES_IN variable. So if you want something that never expires, you can set it to 1000 years.

You'll need to fill in those 3 variables based on your project and then run. node <filename>.js

That will spit out a value that you set the Authorization header to whenever you send a message to your Queue/Topic/etc.

If you don't want to use the node script or you want to read more about this, the documentation as always is your friend.

✌️ Peace!

Module Driven Development - Scaling strategy for your next project

adro.codes — Wed, 23 Nov 2022 21:46:03 +0000

This article was originally posted on papers.adro.codes.

TLDR; Make the move towards developing feature-rich reusable modules instead of once-off components with undetermined dependencies. Module Driven Development aims to move the focus away from code briefly and focus on the cohesion of the codebase.

Cohesion

Cohesion is the action or fact of forming a united whole. We measure cohesion as high/low and strong/weak in software development, aiming for high/strong cohesion is preferable, and is often a sign that your software is reusable, reliable and understandable. When focusing on this trait of software development we create fewer dependencies between the pieces of our software, allowing for modifications in one part that don't cause adverse effects on another.

Knowing this, we as developers aim to implement practices and coding methodologies to improve cohesion, often if not always only focusing on our code and not the structure of our codebase. Module Driven Development (MDD) aims to move the focus away from code briefly and focus on the cohesion of the codebase. Taking a step back and addressing the structure of our folders/files, implementing a consistent structure that is predictable can and will provide lasting benefits to any sized project.

Weak Cohesion

Spoilt for choice without direction. This is the world that many developers find themselves in, especially within the front-end community. One of the most popular UI libraries React is one of these choices and one that is made over 15 million times a week, according to the npm package page. Yet, if you were to look for guidance on a project structure you'll find a similar amount of articles discussing the topic. Why is that? React is un-opinionated meaning, it doesn't enforce any structure on you, it is up to the developers and teams to decide their approach. In my experience, this works great when working in small 1-2 person teams, but not 5-10 person teams across time zones. In team sizes like these, the reusability, reliability and collective understanding suffered.

One piece of famous or infamous advice was;

Move files around until it feels right

In many ways, I agree with the underlying idea, don't overcomplicate too quickly and develop the structure as your application grows. I've followed this advice to some degree on many of my projects and everything worked out however, returning to those projects, later on, revealed a problem with this approach. It was vastly different to the project I am working on now, moving through the project was sluggish and inefficient.

The cohesion was weak.

Through this realisation, I started working on a new approach. One where I respect the advice of moving files around until it feels right, but with the confidence that returning to the project in the future will feel as familiar as the project I am working on in the present.

Strengthen Cohesion

Analysing the problem

We've identified that the approach of "move files around until it feels right" can lead to weak cohesion. That is, it can lead to a codebase that isn't scalable or understandable. Below is a representation of a common project structure for many React (or Front-end in general) projects (left) and the location of various user related components and functionality (right).

At first glance, this appears to be manageable. Different parts are separated into logically categorised folders. However, if you have worked in a codebase similar to this, you'll be aware of the challenges as the project scales. Every new component required adds at least 1 more file/folder to 2 or more of your root folders. Soon, you'll run out of names for files, each folder will contain 50+ files ranging from User related components to your Footer. Additionally, some knowledge sharing is required to define a container component, or your styles will slowly migrate to the respective component folder.

All of these problems and more I have faced coming into large projects that use these techniques. The best I can do is hope that the changes I am required to do only span 1 or 2 files across as many folders, although there is usually still time required to find the start of the breadcrumb trail to follow.

Analysing this structure, we can say that the structure is influenced by the file type. It is grouping .css, .d.ts, .stories.tsx, .gql etc files into separate folders to establish a separation of domains. We can also identify potential scaling concerns, as more pieces are added, these domain folders will continue to grow, increasing the time needed to ramp up development on an existing feature. Finally, identifying cross-component dependencies becomes harder as there isn't a single-entry point that can be easily identified for imports.

With these points in mind, we will look at and compare the proposed structure used for Module Driven Development.

Proposing MDD

Below is the representation of the UserProfile when organising the files using Module Driven Development.

We are still separating different parts of the component into ui, styles etc folders, with one key difference. They are all contained within the UserProfile module. In the next section, I will be outlining some of the principles of MDD, for now, I want to compare this structure to the problems we identified with the previous project structure.

"...the structure is influenced by the file type", "grouping... files into separate folders to establish a separation of domains."
- We are still separating by file type (within a module) however, the key difference here is we are establishing separation through product/project domains rather than the files. These domains are influenced by the problem domain your project is operating in and create a connection between the modules and your requirements.
"...as more pieces are added, these domain folders will continue to grow, increasing the time needed to ramp up development on an existing feature."
- A project will always have a growing file structure. However, with MDD the growth is contained to the top-level modules folder and any module groupings. Rather than spread across several folders.
- The more important benefit here is in regard to updating existing features. Since a feature would be contained within a module, it is much easier to locate the module and be presented with the full picture. It will also lower the cognitive load to scroll through or search for files across your entire solution.
"identify cross-component dependencies"
- This issue now becomes trivial. If you're using something like path aliases with Typescript, you'll be able to do a global search for @module/UserProfile and find all imports referencing that module.
- Additionally, this provides the benefit of being in control of your module API. If your entry is at @module/UserProfile, you can decide what is exported and what isn't. Allowing for both public and private components/functionality. Using this approach, you will be able to identify when a "private" piece of code is needed in another module. This could signal that some refactoring is needed to make a piece of code more globally accessible.

With a fairly simple restructure of our project, we've been able to address each of the major problems identified with the previous approach. The codebase is now easier to navigate and understand. We've strengthened the overall cohesion.

Let's continue and look at 4 principles that I recommend for MDD.

Think narrow and broaden your horizon
Continuous refactoring
Importance of consistent structure
Modules can have modules

Principles

Think narrow and broaden your horizon

It is often tempting to identify something as generic and implement it in a common utilities or lib folder. This principle goes against that way of working slightly, instead of prematurely extracting functionality, first place it within the module that is being worked on, this will:

Encapsulate all the functionality within the module and,
Allow modules to be easily transferred to new projects.

This does open the question of, what if a piece of functionality is needed in another module. That leads to the second principle of Continuous refactoring.

Note: there is a very high chance that your project will still contain a utilities or hooks module. The difference here is in the contents of the folder. Instead of containing ALL utilities or hooks, the code in this folder would have been identified as functionality that is generic and needed in several places. Once again, making tracking dependencies easier.

Continuous refactoring

When a piece of existing functionality is identified as something generic, minor refactoring can take place to move the functionality to a commonplace. I am a big advocate for "leave it cleaner than when you found it". Having the chance to do a bit of refactoring allows you as a developer to revisit old code and clean it up while extracting the functionality. Not only does this keep your codebase healthy, but you may also stumble on existing bugs that haven't been reported yet.

Importance of consistent structure

The modules you write are only as good as their structure. This may take some work with your team to identify the structure that works for them however, the importance here is, to keep it consistent, not just within the current project but within future projects. This will give any team member a basic understanding of where to locate code if they are new to a project. It will also aid new team members, once they are onboarded into one codebase, they can comfortably navigate any other codebase. Below outlines a structure that I use on projects:

ui - a collection of UI (React, Vue, etc) components. You can also place stories here if you're using Storybook.
service - a collection of hooks used throughout the components. This can range from utility hooks to hooks that perform API calls.
context - define Context/State for the module (Read more about Micro Contexts for details on module-based context).
common - define common types, utilities and constants for the module.
styles - any styling required for the components.
integration/data-access - define GraphQL queries, and data transformation needed for the component.
spec - any tests that are required. It is up to you whether to place this in an enclosing folder. For example, ui/spec, common/spec.

Modules can have modules

When it makes sense, or to create further domain separation, a module can have nested modules. Above we defined a UserProfile module, this would make more sense to be a part of a user or authentication module, allowing you to group together Login, Sign up, User profile, User Settings, etc in one folder.

The useful approach here is, that the top-level authentication module can share the consistent folder structure as above allowing all nested modules to share common pieces of functionality with each other, for example, the AuthenticationContext.

Strong Cohesion

We've identified what is causing weak cohesion in a codebase and addressed these concerns with the techniques and principles of Module Driven Development. The techniques allow us to structure projects in a predictable, scalable and understandable way, allowing the codebase to stay consistent across project boundaries.

The cohesion is strong.

Case study

The theory of a methodology and the utilisation of one are two different things. I would like to present a case study of a recent JAMStack project I was a part of. Although the client has to remain anonymous, I will describe the problem tackled and how implementing MDD allowed the codebase to be used by multiple businesses owned by the client.

The client and requirements

The client was a health and fitness brand with two separate businesses, a personal training business and an education business. They needed to continue being separate websites, but ideally share the same components and CMS to allow for a consistent user interface and experience, while allowing staff to have a consistent way to update both websites.

From these requirements, we knew that reusability across the projects would be a necessity. With that, cross-component dependencies should be kept at a minimum to allow them to be shareable without needing to share unrelated code. Unfortunately, the codebases needed to remain separate in this case and we weren't able to utilise a package distributor like npm. We also had to keep the CMS instances separate, so transferring components between websites was a bit manual, which is why the cross-component dependencies would need to be kept to a minimum.

Applying Module Driven Development

We started with identifying the different sections of the website and categorised them into several modules, some of these were top-level modules, while others could be grouped into a more generic module, for example, a banner module which included 4 sub-modules.

The authoring experience allowed the client to construct pages using "Lego Blocks", allowing them to stack sections of a page on top of each other. Each section had it's own Model or Content Type associated with them. Not only does this allow for the configuration of the component to be easily located, but the integration into the CMS could also be included in the module itself.

This allowed us to create a system where modules could be included in the data querying process. Once the data has been fetched, we can loop through the received data, identify the module the data belongs to and render the component to the page.

This central "opt-in" system allowed components to be registered for requesting data and rendering and since both the integration and UI were contained within a module, if a component was developed specifically for one of the businesses, we would be able to copy over the module, register the module and have it immediately available for the client to use in their pages.

This approach allowed the first website to be completed and live within ~2 months, with development on the second taking less than half that. The majority of the effort was spent working with the client to re-develop the IA (Information Architecture) and identifying a handful of modules that were required for the new business, a few of them being ported over to the original project once development was completed.

The most encouraging part for me was, I had little to no input on the second project, however, I was tasked with porting over those selected components. I received a ticket with the title "Move over components X & Y to project one". The following were the steps I took:

Cloned project two.
Located the module folders for X & Y.
Copied them over to project one.
Configured the CMS for project one.
Registered the components.
Pushed the changes.
Moved the ticket to review.

This process took less than an hour to complete. I would call that a win for using the Module Driven Development methodology. The consistent codebase across both projects allowed me to very efficiently navigate the second project, the developers on the second project followed the patterns outlined in project one and created two modules with zero outside dependencies (other than common UI components), making the porting process effortless.

There was, however, one aspect of the project that was unfortunate, the need for separate codebases. Ideally, if you have a client with multiple businesses that should share components and functionality, keeping the code in one codebase would be preferable.

Conclusion

We've been able to define a very important metric that we measure software against, cohesion, and apply that metric to a common practice in the Front-end development world. Through that lens, we were able to identify several key problems that impact these can have on the scalability and developer experience of the codebase. Through utilising the Module Driven Development methodology, we saw these problems lessen, strengthening the cohesion of our codebase, and finally, we looked at a case study where these techniques allowed for rapid development and share-ability between projects.

I hope that you are able to take some of these concepts and apply some of them to your workflow as an engineer. One of the best parts of this methodology is, it does not require a full refactoring of a project. Because we focused on the folder structure employed, you are able to create a modules folder and place future features in their own module, employing the continuous refactoring approach means as older features are worked on, they can slowly be migrated to a module of their own.

Cover Image Credit: Mourizal Zativa

Using the Pub/Sub pattern in a Micro Frontend

adro.codes — Sun, 12 Jun 2022 23:36:20 +0000

A few years ago the idea of a Micro Frontend solution became quite popular. I honestly haven't stayed up to date with the topic so not sure if it ever went anywhere. I did post this article on dev.to to see what other peoples experience/opinion was on the topic. Looking back at the comments, the 1 user who gave a really detailed comment has either deleted their account or their comment... so thats fun.

Anyway, a question I always had was about data sharing. Essentially, if you have a bunch of different isolated apps, possibly in different frameworks, how would you keep shared state synced across the site. For example, user details or authentication state. Maybe 1 app needs to trigger a modal in another (I had this problem recently).

The way I solved it there was using the pub/sub design pattern. The modal was enclosed in a widget with a form to filter some data. It was within the navigation and was used to navigate the user to a area in the website, the navigation was managed by AEM and was disconnected from SPA that made up the rest of the page. In this SPA, there was a "Filter" button, once clicked it published an event, the widget subscribed on that event and once it received a message, would open the modal.

This became a useful pattern in a few spots where really deeply nested components had to communicate to a much higher component. Rather than setting up some context with a bunch of useEffects to listen to changes, I just published and subscribed to some events. Luckily this was only needed less than a handful of times so the solution didn't need to be the most robust, ultra fast, 0.002ms response time type solution.

The way I implementated that was by dispatching a CustomEvent with my data and adding event listeners on components for this event. It meant that I didn't need to keep a list of subscribers because addEventListener did that for me, and I didn't need to loop through my subscribers to push them the changes, again, addEventListener does that for me. Have a look at the mandatory "Counter" example on Codesandbox.

This worked out quite well, the project launched and I haven't thought about it much, until recently.

I wanted to experiment with this design pattern a little to communicate between 2 apps in different frameworks. I decided to use React and Vue, because I have experience with both.

I want to make a disclaimer right now. This is a very basic example, I built it without thinking too much. The chances that there is a Micro Frontend state solution is almost a 100%. If you were going to build something custom, I would probably use something like RxJS.

The first thing I did was build a function called createSubscriptions, this would be used to keep track of subscribers, allow things to subscribe and call a action when the subscribers need to be notified.

function createSubscriptions() {
    const subscribers = new Set();
    return {
        subscribe: (cb) => {
            subscribers.add(cb);
            return () => {
                subscribers.delete(cb);
            };
        },
        publish: (value) => {
            for (const sub of Array.from(subscribers)) {
                sub(value);
            }
        }
    };
}

subscribe: This method allows things to subscribe to and changes and accepts a callback function which will be the action that is called on publish.
publish: Any part of the application can send out a publish event. We go through each subscriber and call their action.

To use this, you would create a topic with this method and then subscribe to it.

const counter = createSubscriptions()

Now that we have that I created a Vue and React application that will listen to changes and allow the user to interact with the counter from each.

React app

function App() {
    const [count, setCount] = useState(0)

    useEffect(() => counter.subscribe(setCount), [])

    const increment = () => {
        counter.publish(count + 1)
    }

    return ( /* UI */ )
}

We need to set up our application state, this allows React to react to any state changes. Additionally we subscribe to the counter with the setCount action, this works out because whenever the publish is triggered it will call setCount with the value. We also return the result of the subscribe method which will unsubscribe the component when it unmounts.

Vue app

createApp({
    mounted() {
        this.unsub = counter.subscribe(this.setCount)
    },
    unmounted() {
        this.unsub()
    },
    methods: {
        setCount(value) {
            this.count = value
        },
        decrement() {
            counter.publish(this.count - 1)
        }
    }
})

I've omitted a few this but the concept is exactly the same as for the React app. I subscribe and pass it a method to update the state. I also have an action to publish an updated count.

To see all the code, check out this codesandbox. To play around with the result, check out the preview.

I will say with the codesandbox link, the editor preview is really wacked when using the unpkg version of the libraries. The preview link is a lot nicer.

Something I might eventually play around with is using this pattern but allow it to feel more "native" to the platform (again, I am sure this already exists).

The idea being that there are methods to provide React with a hook to interact with the topic and create a store for Vue to interact with the topic. This would allow you to subscribe to a topic anywhere across the app with a standardised approach and keep the data in sync, which sounds pretty awesome.

const useCounter = createSubscriptionHook(counter)
const counterStore = createSubscriptionStore(counter)

And that concludes my little adventure of using the Pub/Sub pattern to communicate between two different frontend applications. It was quick, it was dirty but I think it works decently well. Definitely something to keep in mind if I ever have another use case for this in a frontend application.

Peace! ✌️

Response validation with Yup

adro.codes — Mon, 06 Jun 2022 01:06:11 +0000

Problem: Many times in our Frontend we just "accept" that an API response is what it should be. In Typescript we hide behind generics to type cast, but what if our API is a success with a data structure that we didn't expect? This happened a few times in a recent project. The backend logic for the API hit about 4 different services (that we had no control over), each of these are points of failure. Sometimes one would silently fail causing the API to be a 200 with invalid data. I had a great time.

Here is what I am talking about:

async function getMe() {
  try {
    const response = await fetch('http://get.profile')
    const json: Profile = await response.json()
    // Surely `json` will be the shape me need, nothing can go wrong
    renderMe(json)
  } catch (error) {
    // Nothing will ever go wrong
    console.error(error)
  }
}

Now, 99% of the time, this is fine, and 99% of the time, I do this as well... Probably shouldn't, but here we are. We kinda assume that if something goes wrong with the response then the catch will catch it. Otherwise, we're all good. This doesn't just happen with custom fetch calls. In React, if you use a fetch hook, many times it will allow you to pass in generics (useFetch<Profile>()) to say what the shape of the data will be. Again, this works, I do it, but there isn't a lot of safety from incorrect data.

Idea: I have been thinking about is using a validation library, in this case yup to add a extra layer of protection (this idea will work with any validation library). Usually, if we're working with forms we already have a validation library installed, so we aren't really introducing extra dependencies into our project. Additionally, if you're a Typescript user, these libraries can make type definitions a lot easier as well!

Looking at our example above, we need to introduce 2 extra things. One is our schema and the other is validating our json.

Schema

Continuing with the get profile idea, we'll create a profile schema. Depending on how you like to structure your projects. This could be in a profile.schema.ts or profile.model.ts file. Allowing you to separate things a little easier.

import { object, string, date } from 'yup'

export const profile = object({
  email: string().email().required(),
  name: string().required(),
  birthday: date().required()
})

/**
 * For Typescript users, you can import `InferType` from yup
 * and export the Profile type
 * export type Profile = InferType<typeof profile>
 */

Validate the data

Now that we have our profile definition, we can validate our json, and handle any ValidationError that yup might throw.

import { ValidationError } from 'yup'

async function getMe() {
  try {
    const response = await fetch('http://get.profile')
    const json = await response.json()
    const data = await profile.validate(json, {
      stripUnknown: true
    })
    renderMe(data)
  } catch (error) {
    if (error instanceof ValidationError) {
      alert("The response data is invalid")
      return
    }

    alert("Uncaught error occured")
  }
}

You will notice a few things are different here.

We have removed our generics. If the validate call is successful, then we can be confident that data is in our Profile shape.
In the catch block, we can now test for this ValidationError and provide the user some extra details about the issue, instead of a generic 'Something went wrong' message.
(Optional) I also passed in stripUnknown: true to the validate options. As the name suggests, it will remove any data that isn't in our profile schema. This makes the data more consistent but also 'forces' someone to update the schema if additional data is added.

Using a hook library

In the case that you are using a fetch hook of some description. Some of them may have a validation option where you can do the same thing. Alternatively, I've seen that many allow for a transform step. Giving you a chance to change the data before returning it to the user.

const { data, loading, error } = useFetch('http://get.profile', {
  transform: async (json) => {
    const data = await profile.validate(json)
    return data
  }
})

That's all folks

Aaaand... that is it. Nothing else to really add. If you take anything away from this it would be, don't fully trust that your data is as expected. Adding additional checks in your components or logic won't hurt anyone. Validation libraries are usually very performant and already installed in many projects, utilising them to standardise schema definitions, type definitions and API data may provide some additional benefits to your projects. It could also help with mocking data, I am sure there are libraries out there that can take one of these schemas and output some JSON that matches the structure.

Below is a Codesandbox (hopefully it shows up) with this idea implemented, feel free to play around a bit. I did set the console to be open, but it sometimes vanishes so it might be best to open it in a different tab. Play around with the me function and return some weird data to see if the validation works.

Peace! ✌️

Bit of a disclaimer: the ideas in this article are just ideas. I haven't been able to test them out fully yet. Complex data structures or conditional responses might require a more complex schema. I have noticed with complex schemas that the InferType becomes a "everything is optional" type, which isn't always ideal.

JAMstack or Jamstack?

adro.codes — Thu, 03 Jun 2021 23:15:56 +0000

Quick and silly question. I have seen it used both ways and in other ways. But lets do a "poll" to see what the results are.

Comment your answer (or your preferred variation) or react with;

❤️: JAMstack
🦄: Jamstack

Peace ✌️

PWA: FetchEvent.respondWith error on Safari

adro.codes — Fri, 19 Feb 2021 10:00:20 +0000

Recently I have been working on a PWA for a client. I chose to use Gatsby to build out the front end and luckily it comes with some great plugins to help with building PWAs. Mainly the offline and manifest plugins. After configuring those and building out the proof of concept, I deploy the site to Netlify and started testing on different devices.

It all goes off without a hitch until I get to iPad Safari... Where after adding the app to the Home Screen and playing around with it, I turn off my wifi to test the offline mode. And I am met with this lovely error:

Error: "FetchEvent.respondWith received an error: TypeError: There seems to be no connection to the Internet."

You are correct error, there is no internet connection, that is the point.

After spending a while Googling, as you do, I found two things.

Apple doesn't like the term PWA, kinda irrelevant but worth noting.
A LOT of other people were having the same issue.

I tried several StackOverflow and Github solutions, with no luck. Eventually, I decided to go back to basics and create the most bare-bones PWA I could find. Which lead me to this tutorial on Medium by James Johnson. It was the Hello World of PWAs. Literally. Anyway, I followed the tutorial, deployed on Netlify and proceeded to test on iPad, with no issues! So something was wrong with the Gatsby build and not the iPad.

I made two changes to my project, which were all pushed at the same time and ended up fixing my issue. In all honesty, I am not 100% sure which one was the actual fix and at this point, I am too scared to test.

1. I added apple specific metadata

These tags were mentioned in the tutorial I followed above. After looking at the built version of the site, I noticed these apple specific meta tags weren't being generated.

If you're not using Gatsby, I'd recommend adding these meta tags in the <head> of your pages, and seeing if it fixes your issue.

import { Helmet } from 'react-helmet'

const PageWrapper = ({ ... }) => {
  return (
    <Helmet>
      <meta name="apple-mobile-web-app-capable" content="yes" />
      <meta name="apple-mobile-web-app-status-bar-style" content="black" /> 
      <meta name="apple-mobile-web-app-title" content="App Title" />
    </Helmet>
  )
}

I used the react-helmet package to add additional metadata to all my pages. The meta tag that seems the most important would be apple-mobile-web-app-capable.

2. Updated the Workbox `globPatterns`

In my gatsby-config.js file, I updated the manifest plugin options to include cache_busting_mode: 'none', which is required when you specify a new globPattern. Then under the offline plugin I updated the workboxConfig to be:

workboxConfig: {
  globPatterns: ['**/*.{js,jpg,png,html,css}']
}

I found this pattern while diving into the StackOverflow rabbit hole (I can't find the link again...).

That is it, after making those changes and pushing the code. The PWA started working on iPad devices. I'd say to test the first change before trying the second one (if you're using Gatsby), it seems to be the more relevant change.

Hopefully, this has helped you in some way. I spent a few hours looking at this issue so I was pretty happy when it started working. Plus, why not share my solution so other people don't have to spend hours pulling their hair out.

Peace! ✌️

Godot: Show custom editor warnings on Nodes

adro.codes — Sun, 03 Jan 2021 05:13:46 +0000

Have you ever wanted to add the warning triangle on custom nodes that you can see on an Area2D or KinematicBody2D node? Well, then you're in luck because it is actually pretty easy!

For this example, we're going to create a custom Enemy node that requires a Sprite child node. That will give you a good starting point to extend the functionality to fit your purpose.

First, create a new script that inherits from the Node2D (or whatever node you'd like your Enemy to inherit from). I am going to call my file Enemy.gd.

We will define our class name to be Enemy and add the tool keyword. This will allow us to run code in the editor and show the required errors. One note here, I recommend reading the documentation for the tool keyword as there are some caveats that you will need to know about.

The top of your script should look something like this:

extends Node2D
tool
class_name Enemy

Next, we'll add the magical function, _get_configuration_warning. Whenever this function returns a non-empty string, it will show the warning in the editor.

// ...

func _get_configuration_warning():
    return ""

Before we add the logic, create your new Enemy node in a Scene so you can see the warnings appear in the editor. If you've changed the return statement, you should see something similar to this:

We'll only be looking at direct children, so we'll use the get_children method and do a simple boolean check if the check includes a Sprite.

func _get_configuration_warning():
    var has_sprite = false

    for child in get_children():
        if child is Sprite:
            has_sprite = true

    if !has_sprite:
        return "Sprite is required"

    return ""

We create a boolean variable called has_sprite and set it to false by default. Then we loop through all the children, check if the child is a Sprite and set the variable to true. After the loop, we check if the has_sprite variable is still false and if it is, then we return a message saying that a Sprite is required.

If you save the script, the warning should pop up with your message and adding a Sprite as a child node should remove the warning.

The cool thing here is the is keyword, which allows us to;

Tests whether a variable extends a given class, or is of a given built-in type.

Using this, we can test for any other nodes or other custom nodes that we have created.

Again, this is a very simple example but will be a good starting point from which to extend further to suit your needs.

Thank you for reading my article, it really means a lot! ❤️ Please provide any feedback or comments, I'm always looking to improve and have meaningful discussions.

👋 until next time!

Extract key values into an array

adro.codes — Fri, 29 May 2020 10:07:01 +0000

Use case

You have an array of objects and want to pull out all the values related to the amount into an array.

What will happen

We will be creating a Higher-order function that can be used with the reduce method. The method will then loop through the items in an array and pull out all the values for a specific key.

Data structure

I am providing a Vanilla JS and Typescript example, the interface can be ignored if you are using vanilla JS

interface Data {
  id: string
  amount: number
}

const arr: Data[] = [
  { id: "a-a-a-a", amount: 5 },
  { id: "b-b-b-b", amount: 50 },
]

Method - Vanilla JS

export function getKeyValues(key) {
  return (acc, cur) => acc.concat(cur[key])
}

Usage

const amounts = arr.reduce(getKeyValues("amount"), [])
// -> [5, 50]

// Because the method is a HOF, we can create separate methods to use later
const getAmounts = getKeyValues("amount")
const getIds = getKeyValues("id")

const amounts = arr.reduce(getAmounts, [])
// -> [5, 50]

const ids = arr.reduce(getIds, [])
// -> ["a-a-a-a", "b-b-b-b"]

Method - Typescript

// Type definition for a `.reduce` method
type ReducerHOF<A = any[], C = any> = (
    accumulator: A,
    current: C,
    index: number
) => A

/**
 * Extracts the values for a specific key
 *
 * @export
 * @template T
 * @template K
 * @param {K} k
 * @returns {ReducerHOF<T[K][], T>}
 */
export function getKeyValues<T, K extends keyof T>(k: K): ReducerHOF<T[K][], T> {
    return (acc, cur): T[K][] => acc.concat(cur[k])
}

/*
For our example;
T = Data
K = "id" | "amount"
Return type, if K == "id" -> string[]
Return type, if K == "amount" -> number[]
*/

Here we use Generics to add type safety to the method. For example, with vanilla JS you'll be able to get the values for the key comments. Which will return an array of undefined values; not ideal. Of course, you can expand the method to check if a key exists; it will also provide you with autocomplete options within your IDE.

Usage

const amounts = arr.reduce(getKeyValues("amount"), [])
// -> [5, 50]

Takeaways

This method allows you to pull out the values of any key in an array of objects. Using Higher-order functions allows you to encapsulate functionality to make more maintainable and readable code.

Thank you for reading my article, it really means a lot! ❤️ Please provide any feedback or comments, I'm always looking to improve and have meaningful discussions.

👋 until next time!

VS Code define a #region

adro.codes — Wed, 13 May 2020 01:43:10 +0000

just show me

Visual Studio Code is definitely one of my favourite code editors and I use it all the time. Recently I stumbled upon the #region keyword. Using this you are able to wrap a section of code that will be collapsed together. This makes organising code a lot easier and allows you to focus on the functionality you're writing and ignore everything else.

Folding Guide

Example time

I will be showing off how to do this in JavaScript, but it is available in quite a very languages. See the guide above.

function add(a, b) {
  return a + b
}

function minus(a, b) {
  return a - b
}

function multiply(a, b) {
  return a * b
}

function divide(a, b) {
  return a / b
}

Without folding, the best you can do, in terms of folding, is the following;

function add(a, b) {...
}

function minus(a, b) {...
}

function multiply(a, b) {...
}

function divide(a, b) {...
}

Not bad but if you add appropriate jsdoc blocks the functions still take up a decent footprint. With regions, you are able to do the following;

// #region Math functions
function add(a, b) {
  return a + b
}

function minus(a, b) {
  return a - b
}

function multiply(a, b) {
  return a * b
}

function divide(a, b) {
  return a / b
}
// #endregion

Now you are able to collapse the code at the // #region definition, collapsing the code down to;

// #region Math functions ...

Documentation

Stay safe out there ❤️

Coursera: Yes/No/Maybe/??/Aliens?

adro.codes — Wed, 18 Dec 2019 04:45:24 +0000

I am always looking for websites or resources that I can use to learn different things. I briefly looked into Coursera the other day and was wondering...

Is Coursera worth the money and did you find the material worth it (if you used it)?
my discussion question, 2k19

As a bonus, can you list resources that you use regularly to upskill, in any aspect of your career?

I don't have an explanation for "Aliens" in the title

How do you find mentors

adro.codes — Mon, 16 Dec 2019 23:01:58 +0000

Recently I started learning go, I wanted to learn a new backend language and after playing around a bit I started really enjoying it. However, being new to the language I am not sure if I am doing anything wrong or if there are better ways of doing things.

The question is...

How do you go about finding mentors or people to look over your code to provide a second opinion? Unfortunately, none of the people I work with knows go so I can't turn to them.

Are there any websites or places you go to find someone to help you learn concepts and provide feedback on your work?

Note: This doesn't have to be go specific, any guidance on the subject will be great!

Falling in love with Gatsby all over again

adro.codes — Mon, 16 Dec 2019 03:45:02 +0000

Earlier this year I started using Nextjs more and more for developing small web apps. I initially wanted to use Gatsby, because I love it but wasn't able to because I needed authentication and dynamic routes.

You can't do that with Gatbsy...
me being an idiot, 2k19

That is when I read the "Adding App and Website Functionality" and "Building a Site with Authentication" pages on the Gatsby documentation. And oh BOY did it change my view of Gatsby!

Something finally clicked; Gatsby is just react. 🤯 I know right, what a mind-blowing statement. Obviously I knew that Gatsby sites are built with React etc, but I was fixated on the Gatsby way of building sites. Installing a source plugin, creating a createPages loop to render some pages and throw it up on Netlify. However, when I started thinking of it as Create React App with more bells and whistles, anything and everything was possible.

The first thing I did was add Firebase authentication to a site. Now, I am not going to go through any specifics since there is a great tutorial by Auth0 which I used as a base. The basic idea is;

Create a "private" page. /pages/app.js.
Tell Gatsby to render any pages with a slug of /app/* to that page.
Add Reach Router or React Router routes to the app.js page.
Create all your auth methods. Login/Signup, log out, getCurrentUser etc

At this point, I slightly changed my approach from the Auth0 article. I added AppContext using the React Context API. Which kept track of the auth state. I also created a Protected Higher-Order Component to wrap my private routes in. On load, it would check the auth state and either allow the user on the page or redirect them back to the login page.

PRETTY FREAKING COOL!

Now you might be thinking.

Why is this cool
You, maybe... 2k??

Lets talk about it

You can add preview functionality. This is solved with Gatsby Cloud, but we are developers, reinvent everything again. You'd create a pages/preview.js page and once an author is logged in, you can display all the draft posts by requesting them from your data source. Then you can route to /preview/:id, which can then display the content of the page using the same template as the public page. This will require a bit of morphing of data but it will be worth it, eventually.

Ecommerce. Provide an account to your customers to see past purchases or to see exclusive deals.

PAAS. Build out your public site using the usual Gatsby formula and provide potential customers with a quick process between discovery and conversion. Then the app part of your site can use the pages/app.js method described above.

Just think about it this way. Whatever you have built in React before, you can build it with Gatsby. The only difference, you can provide a super-fast, SEO friendly, experience to your customers to convert them quickly. Then use whatever backend or microservice architecture you want.

Hopefully my rambling helped you give Gatsby another chance if you thought that it was too restrictive and couldn't be used to build large scale applications.

DEV Community: adro.codes

Generate a Azure SAS token

Module Driven Development - Scaling strategy for your next project

Cohesion

Weak Cohesion

Strengthen Cohesion

Analysing the problem

Proposing MDD

Principles

Think narrow and broaden your horizon

Continuous refactoring

Importance of consistent structure

Modules can have modules

Strong Cohesion

Case study

The client and requirements

Applying Module Driven Development

Conclusion

Using the Pub/Sub pattern in a Micro Frontend

Response validation with Yup

Schema

Validate the data

Using a hook library

That's all folks

JAMstack or Jamstack?

PWA: FetchEvent.respondWith error on Safari

1. I added apple specific metadata

2. Updated the Workbox globPatterns

Godot: Show custom editor warnings on Nodes

Extract key values into an array

Use case

What will happen

Data structure

Method - Vanilla JS

Usage

Method - Typescript

Usage

Takeaways

VS Code define a #region

Example time

Coursera: Yes/No/Maybe/??/Aliens?

How do you find mentors

The question is...

Falling in love with Gatsby all over again

PRETTY FREAKING COOL!

Lets talk about it

✌️

2. Updated the Workbox `globPatterns`