DEV Community: Ivan Spoljaric

I tried to mount a client-side "attack" on a news website poll by using only Javascript. And I failed miserably.

Ivan Spoljaric — Wed, 14 Jul 2021 00:18:10 +0000

First step - Running the script locally

For academic purposes I tried to create a client-side script to manipulate the results of a random poll on a Croatian news portal

The poll is open at the moment writing, but it probably won't stay that way for long.

Here's the code

The code consists of these steps:

waiting for "DOMContentLoaded" event
closing the cookie banner
selecting a poll answer
MutationObserver indicates changes in the DOMTree target iframe. This means that the results are "in". Then the localStorage is cleared.
a timer, which started running immediately after "DOMContentLoaded", reloads the page after 2 seconds. And the script starts from the beginning

It works as intended if you run it directly in the dev tools console.

You'll probably notice how the code is tightly coupled with the html/css implementation of the web page.

Since I was creating a proof of concept I didn't bother to write the functions in a generalised way.

I used the exact CSS class names from the site, and targeted the poll iframe based on its position in the HTML.

I had a pretty strong hunch that it won't work anyway (not that it stopped me from trying).

Second step - Automating the script

The next step was to think of a way to run the script automatically, without the need to paste the code in the console every time.

So, I created a custom browser extension, which has only one additional manifest.json file.

And that didn't work.

Line 2 is the problem.

  document.getElementsByTagName('iframe')[3].contentDocument;

It doesn't work because of the "Same Origin Policy".

It's a "critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin".

And this also applies to iframes.

"External" iframe's can't be accessed, nor manipulated from a document which is not served on the same origin (domain).

...

For completeness sake, I also tried to use the 3 most popular browser extensions that enable running custom scripts on any web page;

GreaseMonkey
TamperMonkey
ViolentMonkey.

I tested out a few StackOverflow suggestions, related to the configuration of those extensions, in a foolish attempt to beat the system.

But with no luck.

You can't beat the system by breaking its hard rules. Unless you're the One. And it turns out I'm not. At least not yet.

A glimmer of hope

Fortunately not all of my work was in vain.

As I was slowly accepting my fate, and getting ready to completely give up, I stumbled on an alternative approach to this problem.

There's a method called Window.postMessage

And its API looks kind of promising (with regard to CORS issues caused by external iframe communication).

So the story continues. Stay tuned. :)

Conclusion

Do you know any other way, or a hack, to bypass the Same Origin Policy?

Is there another approach to the "external iframe" problem, which I didn't think of?

Or is it just plain impossible to do this on the client (FE) side (which is a good thing I suppose, because it prevents malicious behaviour).

How to create an Angular NavBar with a dynamic slider (and keep your sanity)

Ivan Spoljaric — Sun, 11 Jul 2021 14:17:43 +0000

One must imagine Angular devs happy

Some time ago I started working on a new project with Angular.

I immediately noticed that the learning curve for Angular is a lot steeper than for React. And this is probably more true if you are an absolute beginner with zero to little FE experience.

- The React way of doing things

For example, to start building with React, you can use the CRA (create-react-app) npm package to bootstrap the application. Then you can open the App.js file and start writing your HTML-like (JSX), Javascript, and even CSS code - by using any of the CSS-in-JS tools like StyledComponents. So all of the concerns go into a single file!

You also need to understand some basic concepts like components, state, and props. Plus some extremely basic FP stuff. And that's it, more or less.

Of course, things tend to get more complicated as the complexity of the app grows. And there are more concepts, design patterns, libraries, and tools you need to learn about and eventually master (like React Router, global state management, Redux, R-Thunk, R-Saga, rendering optimisation techniques etc.).

But all of this is optional (not part of the React core library). Most of the extra stuff comes in the form of 3rd party libraries.

- The Angular way of doing things

Angular takes things to a whole new level. If you want to build the famous TO-DO list, the "Hello World" equivalent in the single-page application world, you can't just bootstrap an Angular app and start writing Javascript code in a single file.

First, you have to learn Angular-specific abstractions and some new design patterns, like components, directives, templates, the basics of OOP, dependency injection, and more.

You can argue that I said the same thing for React. In both cases, you need to learn the library-specific, basic stuff before building anything. And this is true. But in my opinion, Angular has much more of that "basic stuff" compared to React.

You also need to know Typescript to write Angular apps. It is not a must, but it is an accepted industry standard.

Also, the HTML, CSS, and TS code is isolated in separate files. It is similar to the classical way of building web apps, with a clear separation of concerns. This has its benefits - but I think I prefer how React handles this.

Once you master the basics and start to think you're finally getting the hang of things, you pass the first hill on the Dunning-Kruger curve, and fall from the peak of "Mount Stupid" to the Valley of Despair.

- Things can quickly become complicated

You eventually realize that Angular has much more stuff baked into its core than React (Router, Animations, RxJS) and that it is a complete SPA development toolbox. This is why people call it a framework. Unlike React, which is "just" a library.

...

The current point in my Angular learning journey is probably somewhere near the bottom of the D-K curve. And I feel like I just started to roll a massive boulder up the hill of enlightenment. Thee bright side is that I'm slowly getting closer and closer to the summit.

The good stuff - How to build a NavBar with a Slider...

...and to keep your sanity during that process.

Last week I implemented the "NavBar with a dynamic slider underneath" component/feature on the project I'm currently working on (for a company client).

So, for the purpose of this blog post I've re-created this component in isolation. I ran into an interesting problem along the way. Solving that problem required some creative thinking.

Here's how the completed component looks like.

The NavBar component has 4 navigation items. By clicking on any of the items, the user is redirected to a predefined route ('/home', '/posts', '/random', '/speed')

The main goal was to indicate the currently active route, and consequently the currently active NavBar item to the user (hence the slider).

Another requirement was that the slider needed to transition smoothly from one item to the other.

The slider is implemented as an additional list element, with some basic styling:

  <!-- navbar.component.html -->

  <ul class="header-menu">
    <li #navElements *ngFor="let item of navItemsList">
      <a 
        routerLink="/{{item.route}}" 
        (click)="calcNewIndicatorDOMStyles()"
      >
        {{ item.name }}
      </a>
    </li>
    <li 
      class="slider" 
      [style.width.px]="activeItemWidth" 
      [style.left.px]="activeItemLeftMargin">
    </li>
  </ul>

  // navbar.component.css

  .slider {
    position: absolute;
    bottom: -5px;
    margin-left: 2.2em;
    border-bottom: 2px solid white;
    transition: 0.3s;
    width: 50px;
  }

You can find the running app here

An additional requirement is that the slider width needed to change dynamically and match the width of the nav item above it.

Nav item width change can happen in two scenarios:

Screen resize. The user can pivot his device.
Text translation change. Simulated with the DE/EN button underneath the component.

If you look at the template file code below, you'll see that I used inline styles to dynamically set the slider's left margin and width:

  <!-- navbar.component.html -->

  <li 
    class="slider" 
    [style.width.px]="activeItemWidth"    <======
    [style.left.px]="activeItemLeftMargin">    <======
  </li>

activeItemWidth and activeItemLeftMargin are calculated in this method:

  // navbar.component.ts

    calcNewIndicatorDOMStyles() {
      this.activeItemWidth = this.router.isActive(routes.name, 
      false)
        ? this.navItemDOMProps?.[0].width
        : this.router.isActive(routes.posts, false)
        ? this.navItemDOMProps?.[1].width
        : this.router.isActive(routes.random, false)
        ? this.navItemDOMProps?.[2].width
        : this.router.isActive(routes.speed, false)
        ? this.navItemDOMProps?.[3].width
        : 0;

      this.activeItemLeftMargin = 
      this.router.isActive(routes.name, false)
        ? 0
        : this.router.isActive(routes.posts, false)
        ? this.navItemDOMProps?.[0].width + 30
        : this.router.isActive(routes.random, false)
        ? this.navItemDOMProps?.[0].width + 
          this.navItemDOMProps?.[1].width + 60
        : this.router.isActive(routes.speed, false)
        ? this.navItemDOMProps?.[0].width + 
          this.navItemDOMProps?.[1].width + 
          this.navItemDOMProps?.[2].width + 90
        : 0;
    }

This method is triggered by the user when a nav item is clicked. Then the new slider position (margin-left) and width need to be re-calculated, so that the slider can transition under the new active item.

So, the tricky part was figuring out how to get the "freshest" DOM styles (after the template re-renders and new properties are computed). To be more specific, I needed the newest nav element offsetWidth value (last render), so that it can be used in the calcNewIndicatorDOMStyles() method to calculate the slider width and left-margin.

The first step was getting the target list elements from the view DOM. I used the ViewChildren decorator for that:

  // navbar.component.ts

    @ViewChildren('navElements') navElements: 
     QueryList<ElementRef>;

and this method to extract the new offsetWidth's:

  // navbar.component.ts

  private getNewNavItemDOMWidths(navElementsList: any) {
    this.navItemDOMProps = navElementsList.map(item => ({
      width: item.nativeElement.offsetWidth
    }));
  }

Finally, I arrived to the reason why I used the word "sanity" in the headline.

This was the hardest part to figure out.

I asked myself which lifecycle method can I use to get the newest, freshly computed DOM style properties?

The most likely candidates were ngAfterViewInit() and ngAfterViewChecked(). All of the other methods fired way too early in the comp lifecycle.

But, to my surprise, calling the getNewNavItemDOMWidths() method from either of those two methods didn't work. I was still getting the old values (from the previous render).

So this:

  ngAfterViewInit() { 
    this.getNewNavItemDOMWidths(this.navElements.toArray());
    this.calcNewIndicatorDOMStyles();
  }

or this:

  ngAfterViewChecked() { 
    this.getNewNavItemDOMWidths(this.navElements.toArray());
    this.calcNewIndicatorDOMStyles();
  }

by itself didn't work.

Example.

Let's say that the current selected language was EN, and that the 4 nav items had widths 10, 20, 30, 40 (i am using random numbers here for the purpose of illustration).

Then if I change the language to DE, this will cause the actual DOM widths to change to 50, 60, 70, 80 - because the text length is different.

If I tried to console log this in the ngAfterViewInit() and ngAfterViewChecked() lifecyle methods, I would get 10, 20, 30, 40 (the values from the previous render)

How I managed to solve this problem.

I formulated the following questions:

Is the ngAfterViewChecked lifecycle method called again, after the template view re-renders and new DOM style properties are computed?

If not, why? How can I force it to run?

My investigation led me to the conclusion that Angular doesn't run this method by default when new DOM style properties are computed and available. It somehow needs to become aware, or forced, to re-run this method when the new styles become available.

So, I solved it like this:

  ngAfterViewChecked() { 
    this.getNewNavItemDOMWidths(this.navElements.toArray());
    this.calcNewIndicatorDOMStyles();

    setTimeout(() => {}, 0);
  }

The call to the setTimeout browser API inside this method forces Angular to re-run it every time, just in case. Because the callback fn inside setTimeout can contain code which can potentially affect the View - after it has already been checked!

And as you probably already noticed the second place in which the this.calcNewIndicatorDOMStyles() is called, is inside the already mentioned lifecycle method.

What's interesting about this solution, is that it also covers the case when the "window" gets resized. Resizing the viewport will trigger this lifecycle method and the new DOM styles will be fetched and used to updated the slider.

And that's it, more or less.

You can find the entire source code here

- The end of this journey

Thanks for reading until the end.

I hope you learned something new about Angular. Or that the code I provided will help you on future projects.

Speaking of which, I have a question for the Angular experts who read through this entire post.

What do you think about my implementation? Is it fine, or is it an obvious antipattern? Is there something I could have done better? Thx

Is functional programming in JS really worth it?

Ivan Spoljaric — Fri, 04 Dec 2020 21:55:12 +0000

I admit that I am still at the beginning of my FP journey, but it's examples like these that make me sceptical about the whole FP hype which is consuming the JS world.

Imperative isOdd:

const isOdd = n => n%2 === 1;

Imperative isEven:

const isEven = n => n%2 === 0;

Declarative / FP isOdd:

// utilities
const mod = y => x => x % y;
const eq = y => x => x === y;

const mod2 = mod(2);
const eq1 = eq(1);

const compose = (fn2, fn1) => v => fn2(fn1(v));

// end result
const fpIsOdd = compose(eq1, mod2);

Declarative / FP isEven:

// utilities
const not = fn => x => !fn(x);

// end result
const fpIsEven = not(fpIsOdd);

The FP style may be more readable (or is it?), but I needed to write 5-6 utility functions to achieve the same end result, so what are the real benefits here?

I wouldn't even know how I could justify writing code like this to my team members.

I am already used to writing FP code in moderation (in my JS/TS projects), like

using .map, .reduce, .filter
constructing pure functions
using redux for global state management (store, pure reducers, actions)
doing shallow/deep copying of function params when needed (to minimise mutating reference variables outside of the function's lexical scope)

And implementing these concepts doesn't require so much overhead in code. To be fair, redux does add a layer of indirection but it's totally manageable and justified.

But the more I learn about advanced FP concepts like pointfree style, composition and piping, the more absurd it seems to use it in my projects.

So for me the jury is still out on this one

Maybe I just can't see the grand and majestic FP forest because of all the composition/piping trees that I'm currently surrounded with.

What do you think about FP? Do you have any experience in using the more advanced techniques in some serious JS/TS projects?

I just created my first NPM package. It ain't much but it's honest work

Ivan Spoljaric — Fri, 24 Jul 2020 14:50:29 +0000

Yesterday I learned that these NPM packages exist:

I have to admit that this both surprised and amused me.

I was under the opinion that the average NPM package is a little bit more contrived than this:

// is-odd

return (n % 2) === 1;

or this:

// is-number

if (typeof num === 'number') {
    return num - num === 0;
  }

But the thing that surprised me the most, is that developers actually use these packages as dependencies on their projects.

is-odd has 500k weekly downloads!

And what makes this whole thing even funnier is that this package has a dependency of it's own, and it is the above stated is-number package.

So the final size of is-odd comes down to cca. 6.5kB.

I don't understand why this package, nor it's sister is-even package, are so popular when it is so easy to "implement" the functionality they offer with vanilla JS (it requires just a single line of code).

But don't get me wrong. I am not trying to be negative.

Who knows why these packages exists and why they became so popular.

For example, one of the reasons might be that the author initially created is-odd because he was practicing how to publish a package to NPM.

But this is just conjecture at this point and it is irrelevant to the remainder of this post and moral of the story :)

I just wanted to explain my motivation before I came to the main topic of the post.

I present to you my very own, and first, published NPM package called linear-array

Here it is: https://www.npmjs.com/package/linear-array

Just to be clear, I am completely aware of the actual uselessness of this package.

But I decided to create it anyway because of the already stated reasons, and more importantly, because I wanted to learn how NPM packages are published.

What it does:

Returns an array filed with linearly increasing numbers, starting from 0 up to the given value - 1 (without offset), or from 1 to the value itself (with offset).

How to use it:

import linearArray from 'linear-array'; // web

OR

const linearArray = require('linear-array'); // server


console.log(linearArray(1)); //=> [0]
console.log(linearArray(3)); //=> [0,1,2]
console.log(linearArray(5)); //=> [0,1,2,3,4]

console.log(linearArray(1, true)); //=> [1]
console.log(linearArray(3, true)); //=> [1,2,3]
console.log(linearArray(5, true)); //=> [1,2,3,4,5]

So it turns out that all of this actually isn't very complicated.

Here's a short workflow on how to do it:

Think of a package that you could create and a unique name (check on the NPM repository that the name is not already taken)
Create a local folder with the same name as your future NPM package
Add the necessary files (index.js, README, LICENSE, and test.js if you want) and fill it with markdown and code
Run git init in your terminal
Push to Github repo with the same name as the local project name
Run npm init in your terminal
Register your profile on https://www.npmjs.com/
Run npm login in your terminal
Run npm publish in your terminal

Take a look of the project repo of linear-array if you get stuck somewhere.

That's it.

Thanks for reading this post until the end.

The moral of the story is, it doesn't matter if you think that your idea for an NPM package is a shitty one.

What does matter is the learning journey.

And because it is fun to try new things like this.

P.S.

If you actually find some use for my package and decide to install it on your project, I'm begging you to reconsider and that you don't do actually do it. 😂

Just copy the code directly from the index.js file on the project repo page.

Cheers!

What music do you like to listen while coding? Here are some of my personal favourites that help me get "in the zone".

Ivan Spoljaric — Fri, 10 Apr 2020 13:10:13 +0000

I've noticed that listening to music while coding helps me to switch into my deep work mode.

Although I sometimes listen to generic stuff, like the current Global Top 50 Hits, most of the time I prefer purely instrumental music (with just a touch of vocals sprinkled in the right places). My personal favorites are soundtracks from sci-fi tv-series and movies.

Why Sci-Fi

I am a huge fan of the sci-fi genre (also fantasy, but to a lesser extent). Ever since I was a small kid I loved reading novels from great writers like Isaac Asimov (I, Robot), Frank Herbert (Dune), Arthur C. Clarke (The Songs of Distant Earth or 2001: A Space Odyssey) and Carl Sagan (Contact). I also loved watching tv-series like Star Trek, Firefly, Stargate SG1, and movies like Star Wars, Sunshine, The Matrix and Interstellar. This is to name a few.

That's why my coding playlists have soundtracks like;

I don't understand completely why these specific songs (or the sci-fi genre in general) strike an "emotional" chord for me, or how they help me to get "in the zone". I believe it has something to do with my emotional attachment to the stories and characters. Like I'm somehow reliving the experiences I had while watching those tv shows or movies.

Today's recommendation

Here is something I've been listening to for the past few days. The season 3 soundtracks of the 2004-2008 Battlestar Galactica TV Series.

This TV series is absolutely awesome and a must-see for every Sci-Fi fan out there. But so is the music (mainly because of Bear McCreary's brilliance).

Anyway, I hope you enjoy this playlist as much as I do. My favourites are: 03-Admiral And Commander, 06-Wayward Soldier and 21-All along the Watchtower.

Battlestar Galactica Season 3 Soundtrack