<h4>A crash course on using Leaflet Maps in NextJS</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*vVM13L6I1UGekROEMx8gpw.jpeg"></figure>Originally published on my <a href="https://tomisin.dev/blog">blog</a>.
<h3>Installation</h3>
<ol>
<li>First, install the leaflet library and its React wrapper with the following command: npm install leaflet react-leaflet</li>
<li>(For TypeScript projects) Install the types for the leaflet library npm install -D @types/leaflet</li>
<li>Install a library containing the default icons (icons might not display properly if this step is omitted) npm install leaflet-defaulticon-compatibility</li>
</ol>
<h3>Usage</h3>
<h4>1. Define your Component</h4>
In a component outside the page where you wish to display the map, create and export a map component similar to this:
<pre>// src/components/Map.tsx import { MapContainer, Marker, TileLayer, Tooltip } from "react-leaflet" import "leaflet/dist/leaflet.css" import "leaflet-defaulticon-compatibility" import "leaflet-defaulticon-compatibility/dist/leaflet-defaulticon-compatibility.css" export default function MyMap(props: any) { const { position, zoom } = props return &lt;MapContainer center={position} zoom={zoom} scrollWheelZoom={false}&gt; &lt;TileLayer attribution='&amp;copy; &lt;a href="https://www.openstreetmap.org/copyright"&gt;OpenStreetMap&lt;/a&gt; contributors' url="https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png" /&gt; &lt;Marker position={position}&gt; &lt;Popup&gt; A pretty CSS3 popup. &lt;br /&gt; Easily customizable. &lt;/Popup&gt; &lt;/Marker&gt; &lt;/MapContainer&gt; }</pre>
<h4>2. Dynamically import your Component</h4>
Next, you’ll need to import your component into your page dynamically. This would eliminate the need to perform Server-Side Rendering (SSR), thereby walking around the compatibility issues that LeafletJS has with SSR.
<pre>export default function MyPage() { const Map = useMemo(() =&gt; dynamic( () =&gt; import('@/components/Map'), { loading: () =&gt; &lt;p&gt;A map is loading&lt;/p&gt;, ssr: false } ), []) return &lt;div&gt; &lt;Map /&gt; &lt;/div&gt; }</pre>
There we have it!
If you found this article helpful, do clap, share and subscribe!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=85f86fccc10c" width="1" height="1" alt="">

A crash course on using Leaflet Maps in NextJS

Displaying a Leaflet Map in NextJS

<h4>Learn how Django models could implement soft delete, without modifying the interfaces and contracts of models and querysets.</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*0jvWLbXENhbH5Q2b"><figcaption>Photo by <a href="https://unsplash.com/fr/@markuswinkler?utm_source=medium&amp;utm_medium=referral">Markus Winkler</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Originally published on my <a href="https://tomisin.dev/blog">blog</a>.
In contemporary architecture, or by design requirements, we often have the need to keep certain records even after they’ve been “deleted” by the user — that’s where soft deletion comes in.
In this article, we would learn how to implement soft delete, while our application maintains its Django-ness (for lack of a better word), and we can still maintain the same interface with our model objects in the same way as we would, if we had hard deletion in place.
<h3>What is Soft Delete</h3>
Soft delete is the process of deleting records in such a way that it is still present in the database while made unavailable to the user. It involves using a flag to mark the record as unavailable, rather than deleting the record from the database.
<h3>Benefits of Soft Delete</h3>
<ol>
<li>Records are easier to restore.</li>
<li>Soft delete operations are faster because we run an UPDATE command in the database. For hard delete, we will run a DELETE command which is generally slower, especially when there are related records across tables.</li>
<li>It keeps are related records in-place.</li>
<li>It is the safer option, in cases where users may need to retrieve deleted information.</li>
</ol>
<h3>Cons of Soft Delete</h3>
<ol>
<li>Added complexity of filtering out records that have been flagged as deleted.</li>
<li>Unique constraints need to be refactored to include the column representing the delete flag, so records which have been soft deleted could be recreated.</li>
<li>In some cases, records might need some unique implementations when soft deleted. For example, when soft deleting card information or payment methods, we might need to clear some sensitive fields like PAN or CVV.</li>
</ol>
Some of these fetch queries will start to look like
<pre>SELECT * FROM users WHERE is_deleted=false;</pre>
Unique constraints would also start to look this, with soft deletion in place:
<pre>CREATE UNIQUE INDEX "users_unique" ON users(is_deleted, email) WHERE is_deleted=false;</pre>
<h3>Implementing Soft Delete in Django</h3>
When implementing soft delete in Django, the first thing that’s required is a base model. This would reduce the complexity and help eliminate the aforementioned cons, as we wouldn’t need to duplicate the soft delete logic in all our models. All we would need to do, is to extend from this BaseModel.
<pre>class BaseModel(models.Model): class Meta: abstract = True # common fields go here</pre>
The first thing we want to add to our base model, is the delete flag. The is_deleted field will inform us about the availability of the record.
<pre>class BaseModel(models.Model): # ...omitted for brevity... is_deleted = models.BooleanField(default=False)</pre>
Next, we override the delete method of the model. So, we can change the default behaviour of our model’s delete from hard deletion to soft deletion.
<pre>class BaseModel(models.Model): # ...omitted for brevity... def delete(self): """Mark the record as deleted instead of deleting it""" self.is_deleted = True self.save()</pre>
With this piece of code in place, we could soft delete records as we would normally hard delete records, and maintain a Django-ic codebase.
<pre>class User(BaseModel): class Meta: unique_together = ['email', 'is_deleted'] name = models.CharField(max_length=24) email = models.EmailField() new_user = User(name="Bolaji", email="user.test@example.com") new_user.save() new_user.delete() print(new_user.is_deleted) # True</pre>
Now that we can soft delete easily, we have to make sure that our query results never actually include any deleted record. We do so by creating a custom manager which filters out the deleted.
<pre>from django.db.models import Manager, QuerySet class AppManager(Manager): def get_queryset(self): return QuerySet(self.model, using=self._db).exclude(is_deleted=True) class BaseModel(model.Model): # ...omitted for brevity... objects = AppManager()</pre>
With this in place, we can replace the default objects field of our Model with our AppManager. This would ensure that when we query using the familiar syntax, we are getting expected
<pre>class User(BaseModel): # ...omitted for brevity... user.objects.filter(...) user.objects.all() # excludes records flagged as deleted.</pre>
Wowza! Now, you can soft delete records while maintaining Django-ic code. Or, maybe there’s one more thing.
It’s possible to invoke delete on a queryset, instead of invoking it on an object. We have already catered for the latter my having a custom delete method in our BaseModel. To cater for the former scenario, we can make a custom queryset class.
<pre>from django.db.models import Manager, QuerySet class AppQuerySet(QuerySet): def delete(self): self.update(is_deleted=True) class AppManager(Manager): def get_queryset(self): return AppQuerySet(self.model, using=self._db).exclude(is_deleted=True)</pre>
Putting this altogether, we have:
<pre>from django.db.models import Manager, QuerySet class AppQuerySet(QuerySet): def delete(self): self.update(is_deleted=True) class AppManager(Manager): def get_queryset(self): return AppQuerySet(self.model, using=self._db).exclude(is_deleted=True) class BaseModel(models.Model): class Meta: abstract = True is_deleted = models.BooleanField(default=False) def delete(self): self.status = DELETED self.save() # Sample model class Post(BaseModel): content = models.CharField(max_length=140)</pre>
Finally, you have soft delete implemented, and you didn’t have to change your contract. Thanks for reading, buddy!
Leave a clap, share this article and do subscribe, if you found this article helpful.
<a href="https://tomisin.dev/subscribe">Subscribe * Tomisin Abiodun</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5c0f95da7f0d" width="1" height="1" alt="">

Learn how Django models could implement soft delete, without modifying the interfaces and contracts of models and querysets.

Implementing Soft Delete in Django: An Intuitive Guide

<h4>A crash-course on the right syntax for applying a style on the first child element nested in the HTML page.</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*RJmEq3E-7hd9LmXT"><figcaption>Photo by <a href="https://unsplash.com/es/@markusspiske?utm_source=medium&amp;utm_medium=referral">Markus Spiske</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Problem</h3>
Suppose we have a div containing several child elements of which we only want to select and style the first child, in CSS.
<pre>&lt;!-- page.html --&gt; &lt;div id="root"&gt; &lt;section&gt;This is the first section&lt;/section&gt; &lt;p&gt;This is the first paragraph&lt;/p&gt; &lt;section&gt;This is the last section&lt;/section&gt; &lt;p&gt;This is the last paragraph&lt;/p&gt; &lt;/div&gt; /* style.css */ #root { background-color: skyblue; }</pre>
Which looks something like this:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*f7Ta6eVxCL7DeR12JLPhIA.png"></figure><h3>Solution</h3>
To select a child element, we can use the CSS child selector syntax parent &gt; child { ... }. This is not to be confused with the descendant selector syntax parent child { ... } — which would select all the appearances of the child element under the parent, irrespective of how many levels down the hierarchy the child element is nested (to get more clarity on the child vs descendant selector, <a href="https://css-tricks.com/child-and-sibling-selectors/#aa-child-combinator">read this</a>).
<pre>/* style.css */ ... #root &gt; section { background-color: gold; }</pre>
Our page will now look something like this:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BTqUuMJGBPHU6Q4Zf-1kRg.png"></figure>Finally, we apply a style to the first child element under a parent, by using the <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/:first-child">CSS first child selector</a> :first-child. This would apply the style to an element, only if it is the first child under its parent (I used to get confused and thought it would style the first child under the specified element)
<pre>/* style.css */ ... #root &gt; section:first-child { background-color: greenyellow; padding: 2rem; }</pre>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*huaqAN0ahr_7tKg7v-vldQ.png"></figure>If this helped, please clap, share and subscribe.
<a href="https://tomisin.dev/subscribe">Subscribe * Tomisin Abiodun</a>
Till next time, buddy!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=fe8da158514" width="1" height="1" alt="">

A crash-course on the right syntax for applying a style on the first child element nested in the HTML page.

CSS: Styling First Child Elements

<h4>Learn how to write cleaner CSS code, by adopting the most popular naming convention in CSS.</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*YoWqZcsqgmbWGV3Y"><figcaption>Photo by <a href="https://unsplash.com/@balazsketyi?utm_source=medium&amp;utm_medium=referral">Balázs Kétyi</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><blockquote>In software engineering, one of the most critical characteristics of clean code is its maintainability.</blockquote>
Code maintainability, in itself, is a ripple effect of several factors. When a piece of software is readable, clear, concise and most importantly ruthlessly consistent, it automatically becomes more intuitive to maintain.
To paraphrase a popular quote…
<blockquote>Bad code is like a joke. If you have to explain it, then it is probably bad.</blockquote>
With that in mind, how can we make our CSS code more maintainable? A fool-proof approach is to adopt a <a href="https://google.github.io/styleguide/">style-guide</a>, coding framework, pattern or architecture, and apply it with ruthless consistency, throughout a project.
There are several style-guides in CSS. In this article, we will be focusing on the most popular naming convention in CSS — the BEM naming convention.
<h3>What’s the BEM Naming Convention</h3>
The BEM naming convention stands for Block, Element and Modifier.
You might have encountered it without knowing. If you are the type to inspect templates from Envato (or your favourite web template hub), you would have come across CSS classes and ids named like .button--primary , .button__title , #pinnedBlogPost__title, .is--bold. Well, that is the BEM naming convention.
To get warm with the idea of the BEM convention, we can imagine different cities in their respective countries, in several continents in the world. For example, London is in the United Kingdom; the United Kingdom is in Europe. In that respect, we can say Europe__UnitedKingdom--London.
Let’s break this down further.
<h4>Block</h4>
Like we saw in the example above, the first part represents a high-level container. This could be anything ranging from a navigation menu, a blog post container, a login form to something more simple like a button. Good examples include: .card, .blog, .post. They are optionally prefixed with namespaces (which we will talk about later in this article)
<h4>Element</h4>
Inside a block, lies the next component of the BEM convention. A singular unit in the container, is an element. This could be the title of a blog card, the text of a button, the links of a navigation menu. They are usually prefixed with two underscores. Examples include: .card__title, .nav__link, .nav__item, #userProfile__name.
<h4>Modifier</h4>
The last part represents a state or variation to which an element is likely to transform — bold, big, small, underline, etc. They are usually prefixed with two dashes, and they appear like: .card__title--bold, .is--bold, .is--underlined.
With the aforementioned convention implemented in our CSS codebase, we rip the benefits of:
<ul>
<li>Improved coding standard</li>
<li>Easy readability</li>
<li>Improved maintainability</li>
<li>Better structure</li>
<li>More reusable code</li>
</ul>
<h3>Namespaces</h3>
Finally, we are going to talk about an ad-hoc concept in To give scopes to the classes in our CSS code, we can introduce special prefixes to their names.
<ul>
<li>
c-: Component c-card__header,c-card--large</li>
<li>
has-,is-: Utility is-big, has-slideAnimation</li>
<li>
js-: Actions js-start, js-exit</li>
<li>
o-: Object o-container, o-container--fluid</li>
<li>
qa-: Testing qa-error, qa-hide</li>
<li>
s-: Scope s-banner, s-jumbotron</li>
<li>
t-: Theme t-dark, t-light</li>
<li>
u-: Utility u-clearfix,u-align-center</li>
</ul>
Did you find this article helpful? Get weekly articles and coding tricks by subscribing to my newsletter.
<a href="https://tomisin.dev/subscribe">Subscribe * Tomisin Abiodun</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=2ef4f9b2f9a6" width="1" height="1" alt="">

Learn how to write cleaner CSS code, by adopting the most popular naming convention in CSS. Photo by Balázs Kétyi on Unsplash In software engineering, one of the most critical characteristics of clean code is its maintainability. Code maintainability, in itself, is a ripple effect of several factors. When a piece of software is readable , clear , concise and most importantly ruthlessly consistent , it automatically becomes more intuitive to maintain. To paraphrase a popular quote… Bad code is like a joke. I

Naming CSS Classes: BEM Naming Convention

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*OBBQT2vOJlzaedoi"><figcaption>Photo by <a href="https://unsplash.com/@hussanamir?utm_source=medium&amp;utm_medium=referral">Hussan Amir</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Identity — the singular pair of lenses, through which the world as we know it, is experienced; even more so the digital world. The very life we live, the pay we get end of the month, our email feed, our social media feed, is based solely on our identity. Now, for a moment, imagine the key to our identities (our digital passport, if you may) are hardcoded and stored in plain strings on the mobile and desktop devices of our users. For the sake of being explicit… <h3>The Dangers of Leaving Apps’ Secret Keys in Client Apps</h3> <blockquote>It takes twenty (20) years to build a reputation, and a few minutes of a cyber-incident to ruin it.</blockquote> <ol> <li> Impersonation: <a href="https://en.wikipedia.org/wiki/Social_engineering_(security)">Social engineers</a> are always on the lookout for identities they can mask on, in-order to extort sensitive information out of people. Now imagine they had the CLIENT_ID and CLIENT_SECRET of all the social login providers you support. They would be able to impersonate your app, and get whatever they can get out of your users.</li> <li> Difficult to revert code on Client Apps: Once a client application release is made, it is near impossible to revert. Even if we release an update, it would be extremely rare for every user to update the app. Meaning we have to take extra precautions in building client-side applications.</li> </ol> <h3>Best Design Approaches For Security</h3> <h4>Client Side Applications</h4> <blockquote>It is safer for secret keys to be on a server (a single device), than for them to be on users’ devices.</blockquote> It is best practice to avoid having secret keys on the client side (especially with web applications). To keep this rule, whenever we can, we should move the secret keys as well as the requests to third parties (which require the use of these secret keys), from the client app to the backend. In the case where this isn’t possible, especially on Android you might refer to this <a href="https://guides.codepath.com/android/Storing-Secret-Keys-in-Android">guide</a>. <h4>Server Side Applications</h4> In our server side application, we need to move our App Secret Keys outside of our application’s codebase and out of our server, into a remotely secure facility. That is where Azure KeyVault comes in! <h3>Securing Your Apps’ Secret Keys with Azure</h3> <h4>Login to Azure Portal (or Setup an Azure Account)</h4> If you have not already created an Azure Account, you can create one for free and enjoy 200 USD worth of access to services. 25+ services of which are always free. <h4>Create Your KeyVault on Azure Portal</h4> Next, we need to create a new Azure KeyVault resource. Head to the Azure Portal, where you’ll find “Create a resource” button at the top row. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ANCdXq_Db3nw2jRZG6LNxA.png"></figure>Now, type in “keyvault” in the text box, and select the first results displayed. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*2febLtSLk6KunI79z_rEmA.png"></figure>You will then be navigated to a page containing more details about the resource selected. Here, click the “Create” button. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Bhgj0SMZC0uZoQIbT5CIwQ.png"></figure>Fill in the form in the “Basics” tab (as shown below) and “Review + Create” which is the last button from the bottom left corner of the screen. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*XKWlE04C3jw-mFezxfTanw.png"></figure>Review the details in the form and click “Create” when you are ready. It will take a moment to deploy the resource for use on the cloud. When it is done deploying, a “Go to resource” button will appear (your newly created KeyVault resource will also show up on the Portal). Click the “Go to resource” button to view your newly created KeyVault. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*o2IvGNaaRYfhzcgSUgccmg.png"></figure><h4>Add a Secret to Your KeyVault</h4> On your KeyVault resource page, locate “Secrets” under “Settings” at the in the left navigation menu, and click it. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cS7ErWfgYNWR8MQJzS59aA.png"></figure>Once you click the “Secrets” link, you will be redirected to this screen. Click the “Generate/Import” button to add a new Secret. Fill in the form, hit create and we can proceed. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BZTZkgQdERwMeQVjqwt9jQ.png"></figure>Once you create your secret, it will show up in the Secrets view. <figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*iprhAWgaLPH4N-BxkUwOIg.png"></figure><h4>Install Azure CLI on Your Machine</h4> To make operations on Azure (from our local machine), we use Azure’s CLI tool. We can install this by using the following commands: <pre># mac brew update &amp;&amp; brew install azure-cli</pre> <pre># linux curl -sL <a href="https://aka.ms/InstallAzureCLIDeb">https://aka.ms/InstallAzureCLIDeb</a> | sudo bash</pre> If you are using Windows, Azure CLI is already a part of Powershell. <h4>Login to Azure CLI or Powershell</h4> After you have installed Azure CLI on your terminal, login to access your Azure resources via the CLI. <pre>az login</pre> <h4>Create a Role-Based Access Control (RBAC) Identity for Your App</h4> Next, you can create an identity for your app. This identity will have authorized access to retrieve secrets from KeyVault; after which we will use the newly created identity in our application. <pre>az ad sp create-for-rbac -n &lt;INSERT_YOUR_APP_NAME&gt; --skip-assignment</pre> The output will be something like: <pre>{ "appId": "SOME_APP_ID", "displayName": "some-app-name", "name": "https://some-app-name", "password": "AUTOGENERATED_PASSWORD", "tenant": "SOME_TENANT ID" }</pre> Save the output somewhere, because we will be using the values later on to access our KeyVault. <h4>Grant Your RBAC-Identity Permission to Access Your KeyVault</h4> Now that we have an identity for our app, we can give that identity the permission to retrieve secrets from our KeyVault. <pre>az keyvault set-policy --name INSERT_KEYVAULT_NAME --spn INSERT_APP_ID --secret-permissions backup delete get list purge recover restore set</pre> <h4>Connect Your App to Your KeyVault</h4> To connect our app to our KeyVault, we need to set our app’s identity (which we got from the Create a Role-Based Access Control (RBAC) Identity for Your App step above) as environment variables — this will give our application the permission to fetch our secrets via the Azure library. <pre># .env</pre> <pre>AZURE_CLIENT_ID = "SOME_APP_ID" AZURE_CLIENT_SECRET = "AUTOGENERATED_PASSWORD" AZURE_TENANT_ID = "SOME_TENANT_ID"</pre> <h4>Make a Call to Retrieve App Secrets</h4> For brevity, this tutorial will use a NodeJS example to demonstrate making a call to retrieve App Secrets First, install the dependencies. <pre>npm install @azure/identity npm install @azure/keyvault-secrets</pre> Now, we can write some code to make the call to retrieve the app secrets. <pre>import { DefaultAzureCredential } from '@azure/identity'; import { SecretClient } from '@azure/keyvault-secrets';</pre> <pre>async function fetchAppSecrets() { const keyVaultName = "MY_AZURE_KEYVAULT_NAME"; const keyVaultUri = ( 'https://' + keyVaultName + '.vault.azure.net' );</pre> <pre> // Use the RBAC specified in the environment as the identity const credential = new DefaultAzureCredential(); const client = new SecretClient(keyVaultUri, credential);</pre> <pre> // Do a test log const secretValue = ( await client.getSecret('SOME_SECRET_NAME').value ); console.log(`The value of SOME_SECRET_NAME is: ${secretValue}`); }</pre> That is it! We now have our app’s secrets secured in KeyVault. <img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=89aaf8222ba9" width="1" height="1" alt="">

Learn how to retrieve secrets stored in Azure KeyVault from Node apps

nextjs

Displaying a Leaflet Map in NextJS

database

Implementing Soft Delete in Django: An Intuitive Guide

Get one coding trick and an article delivered every week at no extra cost

crash-course

CSS: Styling First Child Elements

clean-code

Naming CSS Classes: BEM Naming Convention

app-development

Securely Storing Your Apps’ Secret Keys Using Azure KeyVault