Sebastijan Dumančić

Secure your NextJS app on Vercel with Basic Auth and next-intl route rewrites. Follow our simple guide without breaking the bank!

Recently I’ve needed to add a Basic Auth for deployment protection to a NextJS app that we have deployed on Vercel, but got quite shocked that Vercel bundles up this simple feature in their Advanced Deployment Protection addon, which they charge $150/mo per project. Talk about steep.

Thankfully, NextJS gives us the option to write a custom middleware, and this means we can implement a Basic Auth request before we let people click around our app.

There are already a couple of guides online for this, but it’s unclear how to bundle this functionality with other middleware features, such as next-intl route rewrites.

Follow these steps to get both up and running, and enable Basic Auth on NextJS 14 with App router.

First, here’s a full middleware to copy/paste because that’s what you are here for:

import { DEFAULT_LANGUAGE, LOCALES, pathnames } from '@modules/i18n';
import createMiddleware from 'next-intl/middleware';
import { NextRequest, NextResponse } from 'next/server';

export const intlMiddleware = createMiddleware({
  defaultLocale: DEFAULT_LANGUAGE,
  locales: LOCALES,
  pathnames,
  localePrefix: 'as-needed',
});

export default async function middleware(request: NextRequest) {
  const basicAuth = request.headers.get('authorization');

  /** Request authorization */
  if (!basicAuth) {
    request.nextUrl.pathname = '/api/basicauth';

    return NextResponse.rewrite(request.nextUrl);
  }

  const authValue = basicAuth.split(' ')[1];
  const [user, pwd] = atob(authValue).split(':');

  const validUser = process.env.BASIC_AUTH_USER;
  const validPassWord = process.env.BASIC_AUTH_PASSWORD;

  if (user === validUser && pwd === validPassWord) {
    /** Handle Intl */
    const Response = intlMiddleware(request);

    return Response;
  }
}

export const config = {
  // Match only internationalized pathnames
  matcher: ['/((?!api|_next|_vercel|.*\\..*).*)'],
};


You can see that we first do Basic Auth checks, after which the intlMiddleware is handled. First, we check if the user has previously entered a username and password, and if he did, we take the basicAuth data and use atob to decode that data from base64-encoded string.

We can then compare the entered data with the username and password that we consider valid, which can be saved in the .env file. If both are valid, we forward the request to the rest of the middleware actions.

In case there’s no Basic Auth set, we can redirect a user to an error page placed at /api/basicauth/route.ts:

export async function GET(request: Request) {
  console.log('GET /api/basicauth/route.ts');
  return new Response('Authentication Required!', {
    status: 401,
    headers: {
      'WWW-Authenticate': "Basic realm='private_pages'",
    },
  });
}


And that’s it! You will get prompted to enter a username and password before entering the website for the first time. Future visits will not ask for auth.


Struggling with NextJS? Reach out!

With these easy-to-follow steps, you can secure the app without having to pay additional costs — and that's a win in my book.

Of course, if you have any questions or comments, I'd love to hear them! Feel free to reach out at hello@prototyp.digital.

And if you found this post helpful, please share it with your network. Let's keep the conversation going and support each other in making development a little bit easier.

Development

How to add Basic Auth to NextJS 14 app on Vercel with next-intl

Learn how to set cookies from a site embedded into an iframe using postMessage handlers. 

How to set cookies from an embedded iframe - Prototyped

Our app is written in React so your use case may differ syntactically, but the idea is the same. First up, let's assume you have an existing and working Cookie popup ready. When a user clicks on I accept to accept the cookies, fire the postMessage to the parent element:

window.parent.postMessage(
	{
		msg: 'message-content',
	},
	'*',
);


This exposes the message to the eventual containers your site is loaded with iframe into.

Note the * wildcard which allows any domain to read this message. Change this to the URL of the site you're embedding the site into to allow only that URL.

Next up, in the parent site, you should load the following snippet:

window.addEventListener(
  "message",
  function (e) {
    if (e.data.msg === "message-content") {
      document.cookie = "your_cookie_name=true";

      // Make sure to reference the ID given to the iframe element here.
      const iframeEl = window.document.getElementById("iframe-id");
      iframeEl.contentWindow.postMessage(
        { 
        	msg: 'message-content',
        },
        '*',
      );
    }
  },
  false
);


This snippet adds an event listener that keeps track of the message event. Also, note the wildcard operator (*) which should be replaced with the target origin to control which parent sites you send the message to. Once a message event is fired, we check if it's the same one as we've sent:

if (e.data.msg === 'message-content') 


If the condition above resolves to true, set your cookies in the parent site.

Once the cookies are successfully set in the parent site, repeat the previous step, but the other way around. Send the message using postMessage method on the  iframe element which you get by assigning a unique ID to the element itself.

Back in our app that's now rendering inside an iframe, listen for the message event. Message event here tells us that the cookie has been successfully set in the parent site. When the message is received, fire up your actions to close the popup.

window.addEventListener('message', () => {
	closeCookiePopup();
});


After this, you're done! It's three fairly simple steps that are unnecessarily complicated explanations on the internet.

There are a couple of things to keep in mind:

 * If you're testing this using a plain old HTML document to create an iframe, document.cookie won't work, at least with Chrome. Setting cookies in a local environment doesn't work for some reason.
 * Use serve package from NPM for testing the site(s) on a local machine (https://www.npmjs.com/package/serve).
 * Make sure to update the * (wildcard) to the specific URL you're transmitting the message to.

Thank you for taking the time to read this post, and feel free to share your thoughts and drop us an email at hello@prototyp.digital. 😄

How to set cookies from an embedded iframe

Learn what Firebase saves in the bucket called artifacts and how to clean it up to avoid excessive charges when using Node 10 with Cloud Functions. 

Avoid the unexpected charges with Firebase and Node 10 - Prototyped

Google has announced the end of life for Node 8 support on Cloud Functions sometime in summer 2020. At first, it wasn't a big deal, especially with good support for Node 10 functions, and the upgrade process was painless (well, most of the time).

Suddenly, a couple of months later, some longer-running projects started incurring unexplained charges for Firebase Storage exceeding the free tier (5GB) without any more files being stored in the bucket than usual. What gives?

When you update the functions that you deploy on Cloud Functions to Node 10, it isn't just a simple version bump. Since version 10, Google has completely refactored the way they work with Cloud Functions. From this version on, Google uses Cloud Build to deploy your functions which in turn uses Google's own Container Registry to store instances of the functions in a new Cloud Storage Bucket called [region].artifacts.[your-project-name].appspot.com


Why is Google storing a large amount of data in a bucket called artifacts?

According to the Firebase FAQ,  saving deployment images gives you the following:

Using Cloud Build, Container Registry, and Cloud Storage provides the ability to:
• More easily see and debug issues through detailed function build logs in the GCP console.
• Use build time that exceeds the current build quota of 120 build-mins/day. • View a built container image for your function in Container Registry.

Honestly, I'm not sure this is worth it. Let's see how this change can affect your bill a couple of months down the line. Each time you deploy a function, its snapshot will be saved to the artifacts Storage Bucket, which adds up quite a lot over time. Especially in the development environments where we tend to deploy a lot of stuff to test and given that Google just decided to do this without much notice. Here's an example:

In just a month, we've spent the free tier of storage on our development environment for our long-running project. Note that nothing else in the dev environment didn't come even close to spending the free limit since there's hardly any activity and only test data there.

Note that the visible spike is from a single day of a heavy deployment of many functions.

In a single day, we've spent 1.2GB of 5GB of free storage on our project only by deploying functions.

And this is not something that you easily figure out without actively looking for it. As it stands now, out of 6.4GB used on this project, 86% of storage is used for Cloud Functions snapshots, 14% is used for backup and less than 1% is the actual storage used for the app functionality.

This, of course, incurs a charge. Currently, it sits at $0.03, which left unchecked can easily increase, especially since Google keeps this in your Cloud Storage forever unless you delete it.


How to deal with this?

Fortunately, this is relatively easy to maintain, once you know what you're looking for.

First up, open the Storage section in Google Cloud Platform:

Find the [region].artifacts.[projectId].com bucket, and under click on Lifecycle rules column:

Now, let's click on add a rule button.

Select Delete object as a lifecycle action, and click Continue to setup deletion rules.

Select age and enter the number of days you want to keep content in this storage bucket. You can start with 14 days and lower the number if you need to save more space. And that's it. After Google catches up with your changes, they should remove the images older than 14 days.

Please double-check what you're doing when setting lifecycle rules. If you set the rules on the wrong bucket, you could lose older data you don't want to delete. Use at your own risk.

There's a discussion in Google Groups where some reps from Firebase say that old images are cleaned up but that doesn't seem true or they are not cleaning this up often enough, at least not before it racks up a charge for you.

I'd like to hear if there's a reason to keep this content indefinitely, but so far I can't seem to find one. If they enable us to revert to the previous version or maintain two different versions of functions at the same time that could be useful, but it still makes sense only for a couple of latest versions, not full deployment history. What do you think?

If you want to avoid this kind of files ever creating, Firebase team has recently released a new and updated Emulator Suite which makes it possible to test everything with functions locally and deploy only when it's production-ready, which should minimize the number of Cloud Function images created. You can read more about it here.

Hope this clears up some stuff for you and saves you a couple of $$. Feel free to share your thoughts in the comments or drop us an email at hello@prototyp.digital. 😄

Avoid the unexpected charges with Firebase and Node 10

What issues come along with using service workers? 
Find out what Sebastijan suggests as a solution and what you should keep in mind.  

The thing about service workers - Prototyped

For years, service workers have promised us a feeling of a native app straight in the browser. While specific parts of it are true, such as access to device hardware (gyroscope, orientation sensor, etc.) or background sync, we're still far cry from the native feel in areas such as push notifications, which don't work at all in iOS, and especially offline support. While it's fun to have options and experiment on private, small projects, we can't really consider technologies to be production-ready when they don't support half the devices out there.

With that in mind, service workers also come with a lot of baggage. And we've found that out in a hard way.


Problem with service workers

First, you start developing your app, include service worker because it's a cool new thing to do, you want offline support or definitely want to have all the stuff they bring as an option to use. Months go by, you release v1 of the app and users start rolling in. As it's the first version, things are bound to change, so you implement the first couple of changes. You maybe change some copy around, some links, but soon you get a report that you have a huge bug discovered by one of your users. Maybe something potentially catastrophic for your database, it happens.

Fear not, you patch it up and go about your day. Months go by, and you release v2 of the app, market it like crazy and it reaches some top lists of this and that, and same users that entered your app a couple of months ago, and never again, land on your page and load a completely cached version from the last time they visited, together with any hardcoded values, bugs, funnel changes... essentially a snapshot from the past.

By the time you realize what you have done, you've already saved a snapshot of the app in the arbitrary time to thousands of devices, unable to wipe the cache on their devices, and just sit and wait for them to potentially open your older, less secure version of the app from months ago.


Potential solutions

The way service worker works is when users land on your website for the 2nd time, it loads all assets and files from SW and THEN checks if you have pushed a new SW update in the meantime. If it finds one, it schedules it to be loaded next time you open the website. To make matters worse, normal refresh won't load the new SW content, but you have to close the session (i.e. close all website tabs currently open, or whole browser) and reopen the website to load the new version.

By following this article:

Let Users Know When You Have Updated Your Service Workers in Create React AppShow an alert component when you have pushed a new service worker, allowing the user to update their...DEV CommunityGert Glükmann

I found out that you can insert an action into this process of discovering the new version of SW. The problem is that you can either notify users that a new version is available and leave it up to them to click Load new version which will reload the website properly, or you can force a refresh when the browser figures out that a new SW version is available and installed, which can be after a couple of seconds and well into the time when the app was already interactive, meaning that user started to do something.

Usually, early in the live of an app, updates could be released several times a day, which means users could get a prompt or hard refresh multiple times a day when they land on a website, which is also not a good option.

Other way around, we leave ourselves open to the ghosts of the past by giving users the option to load a new version of the site or not. This way malicious users could take advantage of the app in its pre-patched state.

The worst thing is, when you decide to change your approach, you still have all the old users cached on your previous decision and they don't get the memo that they should reload as soon as they open the site.

Now, when you think about it, it becomes obvious that this is how native apps work from the start. You have a version that is the latest and a lot of previous versions that people have installed, and are still using. But the web isn't native.

Some apps force users to update to new versions even in the native environment. Banking apps first come to mind, which just confirms that the issue exists and if security is an important priority for us, that we have to address it in a creative way.


Conclusion

Many years ago, Web solved the issue where users had to install a new version of software on their devices, where we had to incentivize them to update or upgrade, and support legacy versions with both features and bugfixes. We approach web development with a different mindset than native development. We KNOW we can push updates very quickly to 100% percent of our users, and we are used to pushing experimental features, knowing very well that we can patch them up as we go or remove them fairly quickly if they turn out to be bad ideas. Including service workers turn the tables around once again, by introducing fragmentation, legacy support, and fear of the unknown on the internet, which is something that should be avoided at all costs.

Sure, if we create just a couple of versions all of which are perfect, this is a non-issue, but let's be real, those apps don't exist. So how do you deal with these issues if you still want to keep offline support? Do you use service workers at all? Let me know!

Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital. 😄

The thing about service workers...

Discover helpful tools that will ease your everyday work and improve your productivity for years to come.

We don’t need no servers, we don’t need no source-control - Prototyped

Ok, we do need source control, but bear with me.



For some time already cloud isn’t a buzzword anymore. Normally, buzzwords form around something very popular and emerging at the time and when the hype-train passes, we are left either with obsolete technologies or household names in the industry.

I like to believe that the latter happened with the cloud which paved way to now-established tools like Azure, Firebase, Zapier, Bitrise, Mailchimp, Netlify, CircleCI etc. What once required a whole team of engineers is now available to a single developer, powerful as ever, once again enabling one-man-show products and rise of the so-called indie developer. Tools in the article are not sponsored or endorsed in any way, they are just something I’ve come across in every day work with the technologies that power today’s web and mobile apps. Also this is not meant to be a thorough overview of all tools for every possible scenario — there are a million other tools that can help you build and publish apps the way you want it.

Now that the disclaimers are out of the way, let’s break this down into several categories that have seen major improvements over the years — hosting, CI/CD tools, Cloud infrastructure tools, marketing tools, and general cloud automation tools.


Hosting

Hosting plans have recently come a long way. Right now, you can get free hosting, using Firebase or Netlify.

Choosing Firebase gets you 1GB of storage and 10GB of monthly bandwidth for 0$, while Netlify offers the same 1GB of storage and generous 100GB of bandwidth. On both platforms, you also get free SSL and custom domain support.

Setting up SSL went from purchasing SSL certificates, editing server configuration files and worrying about expiries, redirects and other stuff to ticking a checkbox in some dashboard and forgetting about it.

Just a couple of years ago, this was unheard of, especially 100GB of bandwidth for free, which Netlify currently offers. Even some paid hostings used to offer less than this. This means that you can bootstrap your project well into profitability and serious user base using completely free hosting.

Even when you have to step up a tier and pay, you’re still left with a hosting service which is nicely integrated with their simple CI/CD tools, and, advanced functionalities aside, provides you with plug and play solution for delivering content to your audience in a smart way with almost zero maintenance hours needed.


CI/CD Tools

Continuous Integration / Continuous Delivery, which would be a fancy term for automating repetitive tasks of building and deploying apps to staging and production servers.

What has sometimes required a whole dedicated build server and at least one hairy guy in a basement that maintains that weird thing no-one understands is now a dashboard with more configurations available out-of-the-box that you may ever need. Bitrise, CircleCI, Netlify and probably a dozen others are one registration away, and free tiers are generally generous enough for building and deploying a smaller project without concerns.

Forget about cPanels, drag and dropping to the server, slow FTP connections when you drop 20k files (oops, forgot to delete node_modules). Merge the feature in you source control of choice (again almost completely free, hello Microsoft and GitHub :)) and watch it automatically on development and staging environments. Wonderful!

Read more about using CircleCI & Firebase from our CTO here:

https://medium.com/prototyped/https-medium-com-prototyped-firebase-multi-site-deployment-with-circleci-8770d7dfb42b


Cloud infrastructure tools

When you think about a product, an app, or merely about a complicated website, usually it revolves around design, frontend and backend development.

If you’re tight on budget/time, the design is usually the first to go. You can always use some Material UI library, throw something together and call it a day. UX will suffer, but generally, it should work.

With backend, it’s a bit different story. Normally, you must have a database, you need some architecture planning, you must know at least another programming language, etc. However, with the rise of cloud infrastructure tools like Firebase and Azure, you can skip that part as well.

Firebase, for example, gives you the SDK that ties in with their Firestore/Functions/Storage services with any language you want. So if you know only Javascript, this doesn’t stop you from creating full fledged software in a matter of days.

Not so fond of SQL and it’s relation-based approach, scaling, performant queries and other stuff needed for enterprise-grade solutions? Firebase’s Firstore NoSQL database gives you simple collection-document solution which automatically scales with requests with zero setup required.

If you wan’t a bit more oversight over what’s happening behind the scenes, or you wan’t to use something else then provided NoSQL database, you have Microsoft’s Azure and AWS’s Amplify tech stacks at your disposal.


Marketing

A bit of an outlier between all other tools, marketing is something average developer struggles with or finds irrelevant in building a product. “If the tool is good it will market itself” is a popular saying between those who don’t believe in marketing. Sadly, if no-one knows about your tool or service, its technical excellence is of little use.

What has historically taken a team of people months and thousands of dollars, today you can achieve with a viral post, youtube video or a simple self-expanding campaign (remember Google’s “Sent from G-mail” signature added in every mail back when Windows Live was all the rage? More of similar techniques are covered in Ryan Holiday’s excellent Growth Hacker Marketing: A Primer on the Future of PR, Marketing, and Advertising (non-affiliate link).

For example, if you’re lucky, you can end up on the Reddit homepage (it doesn’t even have to be posted by you). It’s at the same time best and worst thing to happen to your project. You can get millions of views in hours, but also you can get MILLIONS of views in hours, for a website that has chugged along nicely on a micro instance of a shared hosting for 5$ a month.

Protip: Those two don’t work together.

Regarding tools, Mailchimp, Mailjet, and others give you world class tools and one-click marketing campaigns for the basic newsletters out of the box for free or very cheap. If there are people amongst you that have tried to code nice looking email templates that actually work in all weird email clients that people use, you know how pain in the a** it is. I’ll take even basic email templates for free that I know are tested and work in most of the clients.


General automation tools

Market leader here is probably Zapier, but others like Automate.io and IFTTT are also great. Using any of these tools you can integrate unrelated services, and, for example, send marketing emails after successful registration of the user on your service, add your sales numbers from online stores to your custom sheet, notify you of increasingly negative metric on Google Analytics, etc.

While this area isn’t something closely related to software development and product management, a tightly integrated environment of these workers may enable you to focus on the product itself, not pushing papers and filling out tables.

Pieter Levels covers this topic greatly in his book called Makebook (https://makebook.io/)

Here’s where many people would say: “go hire some people to work for you”. Here’s where I say: “avoid hiring, build robots”. Hiring increasing the complexity of your product, business and life. Hiring a person means you need train and manage them and makes you liable for their income and in many countries a lot more than just that (e.g. health insurance). Humans are complex. They’re also relatively slow. Robots can be simple. They’re also very fast. Most of the regular stuff to maintain your product can be automated as a scheduled computer script (run by scheduled cron jobs on your server). Those scripts I like to call “robots”. I have about 700 to 2,000 running depending on server load. They’re such an important part of my business I list them on my team page:

Pieter Levels, Makebook

I can only highly recommend the book which looks at bootstrapping businesses and from another perspective.


Closing word

The point of any of these tools isn’t to make DevOps position obsolete or downplay the importance of a custom backend for a product. Major thing to grasp here is how has the market of cloud-based products matured and now offers tested and stable solutions for most of the problems that early-stage products are facing.

If you don’t have a dedicated backend developer for your product use Firebase. If you are not a DevOps engineer, use Bitrise or CircleCI. Maybe you just want to test market feasibility of a product and need a quick hosting you’re up and running with Netlify or Firebase in a couple of minutes. People run full businesses around just maintaining newsletters through Mailchimp.

The barrier to enter a usually highly demanding and time-consuming area of selling a software product on the internet has never been lower, and with amazing tools like these, it will become even more approachable to the average developer of tomorrow. Let’s make something great with it!

I hope I’ve inspired some of you to build your own things, or to simplify processes that you’ve maybe inherited from days past. Either way, let me know if I skipped something important, or wrote something just plain wrong. Write in the comments if you have any thoughts about this or contact me at sebastijan@prototyp.digital. Drop us a visit at prototyp.digital if you’re just clicking links now. Cheers!

We don’t need no servers, we don’t need no source-control

In this step by step article, you can find out how to create a draggable chat-heads in React Native.

Draggable chat-heads in React Native - Prototyped

Most of us are familiar with Facebook’s floating heads that are screaming for your attention on top of all other apps. At the time, it was a novel concept, somewhat annoying, but still, something new.

Recently, we’ve had a client that requested similar behavior, just in-app, which would show draggable profile photos which could be paired by overlapping one over another.

Since you’re probably skimming this part to see if a solution you’re looking forward is here, let get straight to the point.

We’ve used panResponder and wrapped each person in one.

constructor(props: Props) {
        super(props);
        this.pan.addListener((value) => this.position = value);

        this.panResponder = PanResponder.create({
            onMoveShouldSetPanResponder: (evt, gestureState) => true,

            onPanResponderGrant: () => {
                this.pan.setOffset({
                    x: this.position.x,
                    y: this.position.y
                });

                this.pan.setValue({ x: 0, y: 0 });
            },

            // Move object while onPress is active. Snapping is handled later.
            onPanResponderMove: Animated.event([
                null, { dx: this.pan.x, dy: this.pan.y }
            ]),

            // Handle swiper behaviour after object is released.
            onPanResponderRelease: (e, { dx, dy, vx }) => {
                // Fix jumping when moving the object second time.
                this.pan.flattenOffset();

                // Send ending position to parent component.
                this.props.calculateOverlapping(dx, dy, this.props.person.id);

                // Animate springy tuff.
                Animated.spring(this.pan, { toValue: { x: 0, y: 0 } }).start();
            }
        });
    }

See the whole panResponder code on https://gist.github.com/sebastijandumancic/4ff2184aac4dd88770f6bb66f5be998f


Register initial people position

Each person is wrapped in an Animated.View component which means it’s draggable. Animated.View, just as normal View, has an onLayout event which is invoked on mount and layout changes.

Once that event is triggered, we can register this person initial position. They are positioned absolutely, but when reporting position it will use XY coordinates based on the parent they are on (0,0 will be top left corner of the parent element).

const newPersonPosition = new PersonPosition(Math.trunc(event.nativeEvent.layout.x + 30), Math.trunc(event.nativeEvent.layout.y + 30), userId);

The position is truncated since we don’t need extreme precision that horizontal and vertical displacements report (dx and dy in onPanResponderRelease).

PersonPosition here is just a constructor that creates an object with its horizontal and vertical position, together with userId which we can use later on to trigger events on that specific user.

Also, I’ve added 30, a magic number, which is half of the width and height of a component. Reported location (event.nativeEvent.layout.x) is a position in the top left corner of the component. If you want to be scientific about this, the proper way would be to check for a component's width and height and add half of it, but I know mine is 60, so I just added half manually. Now we save this since it’s a center of a component, and we need that for overlap calculation.

Position for each person is then pushed into an array which is saved to state:

peoplePosition.push(newPersonPosition);
this.setState({
    peoplePosition
});

This is to have an easier way of comparing future dropped components to all of the others (using array’s find method).


Checking for overlapping

Main part is to check for overlapping after the user releases the person. We can get the drop coordinates like this:

onst droppedX = Math.trunc(draggedPerson.startingPointX + dx);
const droppedY = Math.trunc(draggedPerson.startingPointY + dy);

Where we take dragged person’s horizontal starting point and add the horizontal displacement and repeat for the vertical axis. The result is once again truncated to remove unneeded decimals.

Then, that ending position of the person is checked against the positions of all people that were not dragged:

const matchedPerson = notDraggedPeople.find((personPosition: PersonPosition) => Math.abs(personPosition.startingPointX - droppedX) < 30 && Math.abs(personPosition.startingPointY - droppedY) < 30);

If the dropped person is anywhere inside a set distance from any of the people, we have a match! Here the radius is hardcoded to 30px, but you can set it to whatever you want.

Maybe the best is half the width of an element + some buffer to make it easier to overlap successfully. You definitely want to avoid making it larger than the total width of the elements you’re overlapping to avoid false positives.

The distance of 0 means that the two components are perfectly overlapped (their centers match). Distance of 30 (in our case) means that they are touched by the edges. Tweak this number to determine how precise you have to be in order to get a sucesfull match.

If a match is successful, just push the person to the matchedPeople array and save it to the state:

let matchedPeople = [];
if (matchedPerson) {
    matchedPeople.push(matchedPerson);
    this.setState({
        matchedPeople
    });
}


Trigger action after overlapping

Finally, you probably want to do something after the user overlaps two heads successfully.

In our case, we just listened to state change for matchedPeople in ComponentWillUpdate:

componentWillUpdate(nextProps: Props, nextState: State) {
    if (nextState.matchedPeople.length) {
       // Navigate away from the screen
    }
}

You should check for changes here to avoid excessive triggering for each component updates, but since we navigated away from this screen once a successful overlaps occur (matchedPeople array is populated), it’s a simple logic to check for.

Provided you’re experienced with panResponder, this code should be easy to replicate. In case you need a refresher on panResponder, I’ve written another article which tackles rotateable circle to select items here:

Circular Swiper using Pan Responder and Animated libraryOr how little is needed for something to break Android in React-Native For the last month at Prototyp [https://prototyp.digital/] we’ve been working onsome quite interesting stuff. The goal was to create a circular swiper forselecting products to scan — something like this: It’s a circle which s…Prototyped - Prototyp.digital blogSebastijan Dumančić

Did I mess up somewhere? Have better ideas? Drop us an email at hello@prototyp.digital or visit us at https://prototyp.digital. Cheers!

Draggable chat-heads in React Native

Follow this tutorial and learn how to clip an image using a custom path in react-native-SVG.

React Native SVG Image & ClipPath - Prototyped

How to clip an image using a custom path in react-native-svg.



As promised in the previous article I’d like to share our experiences with using react-native-svg and clipPath in React Native. There are a couple of tutorials about this, but I found them kind of hard to understand or they don’t cover specifics of Android and/or iOS, and just focus on a single platform.


Here’s how to do this, on both platforms, using react-native-svg's clipPath

First, you need to create this (or any other) shape in any vector drawing software, and export it as SVG. Here’s how it looks like exported from Adobe Illustrator:

<?xml version="1.0" encoding="utf-8"?>

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 828.2 827.8" style="enable-background:new 0 0 828.2 827.8;" xml:space="preserve">
    
<path d="M762.2,189.9c-17.4-27.1-38.1-52.2-61.3-74.5c-23.9-22.9-50.8-43.1-79.8-59.8C528.3,2,419.9-13.5,315.9,11.9 c-50.6,12.4-97.8,33.8-140.2,63.6C131.9,106.3,95,144.9,65.9,190.1c-0.1,0.2-0.2,0.3-0.3,0.5c-3.4,5.8-1.4,13,4.4,16.4l308.3,178 c8.4-10.4,21.3-17.1,35.8-17.1c14.4,0,27.2,6.6,35.6,16.9l308.4-178c1.9-1.1,3.4-2.6,4.5-4.4C764.8,198.5,764.7,193.7,762.2,189.9z"/>
    
</svg>

It contains a lot of junk like comments, headers, and other superfluous stuff which we don’t need. But we need the generated path value as well as viewBox size. Save those.

As stated in documentation available here you must put clipPath inside defs element of the SVG which is used to store graphical objects that will be used later on (more on that here).


For our example, it looks like this:

<Defs>
    <ClipPath id="clipPath">
    <Path fill="white" stroke="gray" strokeWidth="3"
        d="M762.2,189.9c-17.4-27.1-38.1-52.2-61.3-74.5c-23.9-22.9-50.8-43.1-79.8-59.8C528.3,2,419.9-13.5,315.9,11.9 c-50.6,12.4-97.8,33.8-140.2,63.6C131.9,106.3,95,144.9,65.9,190.1c-0.1,0.2-0.2,0.3-0.3,0.5c-3.4,5.8-1.4,13,4.4,16.4l308.3,178 c8.4-10.4,21.3-17.1,35.8-17.1c14.4,0,27.2,6.6,35.6,16.9l308.4-178c1.9-1.1,3.4-2.6,4.5-4.4C764.8,198.5,764.7,193.7,762.2,189.9z"/>
    </ClipPath>
</Defs>



After that, you must define Image which will be used to fill this area (an image that will be clipped by this path) and apply clipPath id to it so that the image knows which element to refer to.

The trick here is that you must wrap Image element with a Group element (G) in order for it to work on iOS, but without G for it to work on Android.


Here’s an example:



{Platform.OS === 'ios' ? (
    <G clipPath="url(#clipPath)">
        <Image 
            x="0" 
            y="0" 
            width="100%" 
            height="100%" 
            preserveAspectRatio="xMidYMid slice" 
            href={{ uri: 'image url here'}} />
    </G>
) : (
    <Image 
        clipPath="url(#clipPath)"
        x="0"
        y="0"
        width="100%"
        preserveAspectRatio="xMidYMid slice"
        href={{ uri: 'image url here'}}/>
)}



For some reason, Android Image just doesn’t like being wrapped in G (it doesn’t clip properly), and if you add clipPath directly to the Image on iOS it will just fail to compile using Typescript. So there’s that.

I’ve used Platform module directly from react-native to detect the platform and apply changes accordingly. Note the clipPath reference to the path defined above using id which is defined in the path object.

Besides that, you just need to wrap it inside the SVG object containing the same ViewBox dimensions as in the exported SVG object from the start. You can find the entire example here: https://codesandbox.io/s/q8rn840nxq. It’s not runnable directly in the browser, sorry.

And that’s it. It’s quite simple, but somehow tutorials fail to provide all the steps for this to work out of the box for all platforms. I hope this helps!

Want to get in touch? Drop us an email at hello@prototyp.digital or visit us at https://prototyp.digital. Feel free to point out if something is incorrect or you have a better way of doing stuff, we’re all here to learn :) Thanks!

Thanks to Luka Buljan.

React Native SVG Image & ClipPath

Uncover all tips and tricks that we used to create a circular swiper for selecting products to scan.

Circular Swiper using Pan Responder and Animated library - Prototyped

Or how little is needed for something to break Android in React-Native

For the last month at Prototyp we’ve been working on some quite interesting stuff. The goal was to create a circular swiper for selecting products to scan — something like this:

It’s a circle which should rotate based on user swiping gestures. After a bit of exploration, we landed on a couple of libraries and technologies to create this. Here’s what it takes:

 1. Pan Responder: https://facebook.github.io/react-native/docs/panresponder
 2. Animated library: https://facebook.github.io/react-native/docs/animated
 3. react-native-svg: https://github.com/react-native-community/react-native-svg

Main requirements are that the images are dynamic and clipped by a custom SVG path and that it rotates and snaps to correct portions of the circle. Seems easy enough, and the final result actually is, but the road to success is paved with a lot of slow animations.

Friendly notice: If you’re here to read about clipPath and react-native-svg, I’ll cover this in the second post and update it here when it lands. Nothing more for you for now — sorry!


Pan Responder

PanResponder is great — it’s a React Native wrapper of the responder handlers provided by the gesture responder system.

Main methods used are:

 * onMoveShouldSetPanResponderCapture which sets up the component to be tracked by PanResponder.
 * onPanResponderGrant which is being triggered immediately when user taps or swipes for the first time in a single instance. In this method setOffset should be triggered on the Animated value to transfer last panned value to offset as a sort of memory, or how much has the object moved (or in this case rotated) since the beginning of the first swipe interaction.

onPanResponderGrant: () => {
    this.pan.setOffset(this.pan._value);
}

 * next is onPanResponderMovewhich is continuously called for each pixel of user movement on the screen. Here we bind it directly to the value of Animated — more on that later.

onPanResponderMove: (e, gestureState) => {
    this.pan.setValue(gestureState.dx)
},

 * And finally, onPanResponderRelease where most of the calculations take place — here we decide where the circle will snap after the user releases the tap. This method is a bit complicated so let’s go through it step at a time:

onPanResponderRelease gives you access to precalculated values of dx and vx which corresponds to horizontal displacement and horizontal velocity, respectively. Besides them, their vertical counterparts exist (dy and vy) but we won’t be using them in this example.

With this in mind, we can create the following snippet:

const handlerValue = Math.abs(dx) > SCREEN_WIDTH / 8 || Math.abs(vx) > 1.3 ? this.getAmountForNextSlice(dx, this.pan._offset) : this.snapOffset(this.pan._offset);

Which calls this.getAmountForNextSlice if user has swiped far enough or with enough force, or this.snapOffset and send it the last offset state to return user to the previous position.

getAmountForNextSlice = (dx: number, offset: number) => {
// This just rounds to the nearest 200 to snap the circle to the correct thirds
const snappedOffset = this.snapOffset(offset);
// Depending on the direction, we either add 200 or subtract 200 to calculate new offset position.
const newOffset = dx > 0 ? snappedOffset + 200 : snappedOffset - 200;
return newOffset;
};

Or in case we return user:

snapOffset = (offset: number) => Math.round(offset / 200) * 200;

After we have moved the user to the next product or snapped him back to the previous one, this.pan.flattenOffset(); method is called (an Animated.Value method), which, as stated in the documentation, Merges the offset value into the base value and resets the offset to zero. The final output of the value is unchanged. — https://facebook.github.io/react-native/docs/0.8/animatedvaluexy#flattenoffset

Finally, the transition to new value can be animated using Animated.spring:

Animated.spring(this.pan, {
    toValue: handlerValue
}).start(() => this.simplifyOffset(this.pan._value));

Animated.spring also accepts a callback function, which is in this case this.simplifyOffset() where we map offsets that are more than one full circle back to 0 to avoid offsets in thousands to simplify calculations.


More on Animated Library

Animated is an animation library that works great together with PanResponder. To keep the article somewhat short, I’ll just point you to official documentation to the whole library (https://facebook.github.io/react-native/docs/animated) and cover one thing we haven’t encountered above.

In previous section, we have called Animated.spring() method which one of integrated animation types for Animated values. In order to use it, you must declare a variable as an Animated Value:

private pan: AnimatedValue = new Animated.Value(0);

And also wrap the element you wish to animate with Animated.View component:

<Animated.View style={{transform: [{ rotate: this.pan.interpolate({ inputRange: [-200, 0, 200], outputRange: ['-120deg', '0deg', '120deg']})}]}}
{...this.panResponder.panHandlers}
>
<SwiperSvg products={products} />
</Animated.View>

Notice the ...this.panResponder.panHandlers which is used to instantiate pan handlers, obviously, on this element only. There is more styling involved, but it’s removed here, for brevity.

What this does is it binds the change to the pan distance (the inputRange value) to the rotation amount (the outputRange value). The numbers here are tweaked to match the desired speed and springiness, but 200 is important as we have snapped all amounts to that earlier, to ensure proper orientation of each section after swiping is done. To increase or decrease the speed of swiping this number should be adjusted everywhere.


Performance Issues

Now, everything said earlier is great, but what almost brought a whole project to a halt and back to the drawing board was the performance on Android.

On one side iOS handled things beautifully, almost locking 60fps on an iPhone 5 back from 2012, while modern high-end Android devices struggled with maintaining half of that, and older ones being flat out unusable.

First, we have optimized images, trying to use FastImage (https://github.com/DylanVann/react-native-fast-image) — which helped in some cases, but regarding swiping FPS, we weren’t sure if it was the placebo kicking in or actual improvement, so no real improvement here.

After that, we’ve spent quite some time optimizing styles, as using Stylesheet objects is far faster than defining new style object each time. You can read more about this here: https://facebook.github.io/react-native/docs/stylesheet. This helped with consistency, but again no real benefits to the performance.

One of the most often bits of advice is to use a native driver, by enabling a flag in the Animated config:

useNativeDriver: true

Which helps quite a lot actually, but it completely breaks the animation calculation as the offset and values of the pan is miscalculated since the animation steps are asynchronously sent and executed in the native realm.

In the end, we’ve spent full 10 days optimizing and trying to find a solution, even decided at one point to write everything in native, when we hit a one-line breakthrough.

To get a little perspective, we come from web development, and we brought best practices with us. Some of them had to be abandoned for mobile, some updated, but some gave us some serious headaches. For example, it is normal to define a border radius of an element as ‘1000’, as you’re sure it’s ‘enough’, on the web. On mobile, especially Android, it is not.

This one line, this borderRadius: 1000 on a button which is positioned in the middle of the swiper (empty space on the drawings), caused a 50–80% reduction of fps while swiping on Android.

The solution is to use the minimum amount needed for the button to be fully circular. It needs to be at least half of the element width, so if the element is 50x50, borderRadius should be at least 25. Everything above that can give performance issues and is useless.

We were mind-blown. It’s hard to believe that a one-liner can cause so much trouble and be so hard to detect in the code. However, it is what it is. I just hope this helps you, weary internet lurker.

In the end, here is how it looks on a simulator (mind that this GIF is capped at 20fps, it’s a lot more fluid on a real device):


Conclusion

By using PanResponder and Animated, it’s fairly easy to create desired animation and gesture control. One should be very careful about performance on Android though — very small details in Android implementation can bring the whole experience to a halt even on powerful devices. However, once you go past that, you’re left with great user experience and a fun swipeable component.

Have something to add? Please do, we’re always eager to learn more, as we’ve only started RN development. If you want to get in touch, send us an email to hello@prototyp.digital or visit us at https://prototyp.digital. Thanks!

Thanks to Vlatko Vlahek.

Circular Swiper using Pan Responder and Animated library

Luka Buljan

Learn how to structure a self-validating and reusable input component that returns both the input value and validation result to its parent.

React Native self-validating input - Prototyped

Sooner or later, you get sick of validating stuff manually.

In order to be more efficient and avoid repetitive work, but still stay flexible we asked ourselves how do we structure a self-validating and reusable input component that returns both the input value and validation result to its parent?


There are a couple of marks to check:

 * component must be reusable
 * It should handle validation, label, error messages and everything else related to a single input element
 * easily extendable (to handle new requirements)
 * for now, it should handle only simple text input component
 * support for email, password, and other simpler types (name, address, notices, etc.)

While not exhaustive, this component should address validation and handling of basic data input for 90% of forms. For that special cases of weird phone numbers or special formatted discount code you can always write a custom component.

TL;DR we managed to replace more than 90% of our input fields with this component throughout the project.


Example

Say you have a screen where you have to enter an email address and name and validate both.

Something like this:

(...)
interface ParentComponentState {
    email: string;
    emailValid: boolean;
    name: string;
    nameValid: boolean;
// specify all state prop types
    [prop: string]: string | boolean | undefined;
}
export class ParentComponent extends React.Component<
    {},
    ParentComponentState
    > {
    state = {
        email: '',
        name: '',
        emailValid: false,
        nameValid: false
    };
    
    handleSubmit = () => {
      const { email, name, emailValid, nameValid } = this.state;  
      const formValid = emailValid && nameValid;
if (formValid){
        // Do something with name & email
      }
    }
    
    render() {
        return (
            <ScrollView contentContainerStyle={theme.scrollView}>
                <Button title="Submit" onPress={this.handleSubmit}/>
            </ScrollView>
        );
    }
}
(...)

As said above, we wanted to avoid writing handlers for each specific input type. After all, you do only need two handlers — to set the value and validation state and one for submitting everything.

(...)
handleSetValue = (prop: any, value: string, isValid: boolean) => {
  this.setState({
    [prop]: value,
    [`${prop}Valid`]: isValid
  });
};
  
handleSubmit = () => {
  const { email, name, emailValid, nameValid } = this.state; 
  const formValid = emailValid && nameValid;
if (formValid) {
    // Do something with name & email
  }
};
(...)

These two methods, together with invoking the actual component and passing neccessary props (shown below) are everything that’s required in the parent component.

<ValidatedInput
  value={name}
  propName="name"
  placeholder="Your name"
  label="Your name"
  editable={!somethingIsHappening}
  changeCallback={this.handleSetValue}
/>
<ValidatedInput
  value={email}
  propName="email"
  placeholder="Your email"
  label="Your email"
  editable={!somethingIsHappening}
  changeCallback={this.handleSetValue}
validationType={ValidationMethod.Email}
/>

Now, the input component. You will have to replace styles with your own in the code.

(...)
interface ValidatedInputProps extends TextInputProps {
  value: string;
  propName: string;
  label?: string;
  validationType?: ValidationMethod;
  minLength?: number;
  optional?: boolean;
  exists?: boolean;
  compareValue?: string;
  emptyErrorText?: string;
  invalidErrorText?: string;
  changeCallback: (prop: any, value: string, isValid: boolean) => void;
}
interface ValidatedInputState {
  isValid: boolean;
  isEmpty: boolean;
  focused: boolean;
}
export enum ValidationMethod {
    Email = 'EMAIL',
    Date = 'DATE',
    Password = 'PASSWORD',
    Comparable = 'COMPARABLE'
}
export class ValidatedInput extends React.Component<
  ValidatedInputProps,
  ValidatedInputState
> {
  state = {
    isValid: true,
    isEmpty: false,
    focused: false
  };
componentDidUpdate(prevProps: ValidatedInputProps) {
    const { exists, value } = this.props;
    if (prevProps.exists !== exists) {
      this.validateByType(value);
    }
  }
getEmptyErrorText = () => {
    const { label, emptyErrorText } = this.props;
    return emptyErrorText
      ? emptyErrorText
      : label
        ? `${label} is required.`
        : `This field is required.`;
  };
getInvalidErrorText = () => {
    const { label, invalidErrorText } = this.props;
    return invalidErrorText
      ? invalidErrorText
      : label
        ? `${label} is invalid.`
        : 'Value is invalid';
  };
handleSetValue = (event: any) => {
    const value = event.nativeEvent.text.trim();
    this.validateByType(value);
  };
validateByType = (currentValue: string) => {
    const {
      maxLength,
      validationType,
      optional,
      compareValue,
      changeCallback,
      exists,
      propName
    } = this.props;
    
    const defaultMinLength = optional ? 0 : 1;
    let { minLength } = this.props;
    minLength = minLength || defaultMinLength;
    
    let isValid;
    switch (validationType) {
      case ValidationMethod.Email:
        isValid = this.validateEmail(currentValue);
        break;
      case ValidationMethod.Password:
        isValid = this.validatePassword(currentValue);
        break;
      case ValidationMethod.Comparable:
        isValid = this.validateComparable(currentValue, compareValue!);
        break;
      default:
        isValid = this.validateDefault(currentValue, minLength, maxLength);
        break;
    }
const isEmpty = optional ? false : !currentValue;
    if ((isEmpty || exists) && !optional) {
      isValid = false;
    }
this.setState({
      isEmpty,
      isValid
    });
changeCallback(propName, currentValue, isValid);
  };
validateEmail = (value: string, exists?: boolean) =>
    validation.EMAIL_REGEX.test(value);
validatePassword = (value: string) => {
    return (
      value.length >= validation.PASSWORD_LENGTH_MIN &&
      value.length <= validation.PASSWORD_LENGTH_MAX
    );
  };
validateComparable = (value: string, compareValue: string) =>
    value === compareValue;
validateDefault = (value: string, minLength: number, maxLength?: number) => {
    return maxLength
      ? value.length >= minLength && value.length <= maxLength
      : value.length >= minLength;
  };
handleFocusEvent = () => {
    this.setState({
      focused: true
    });
  };
removeFocusState = () => {
    this.setState({
      focused: false
    });
  };
render() {
    const { isValid, isEmpty, focused } = this.state;
    const { label, value } = this.props;
    
    return (
      <View>
        {label && (
          <Text
            // style={ focused ? FOCUSED_LABEL_STYLE : undefined }>
            {label.toUpperCase()}
          </Text>
        )}
        <TextInput
          // style={focused ? FOCUSED_INPUT_STYLE : DEFAULT_INPUT_STYLE}
          value={value}
          onFocus={this.handleFocusEvent}
          onBlur={this.removeFocusState}
          onEndEditing={this.handleSetValue}
          {...this.props}
        />
        {isEmpty && (
          <Text>
            {this.getEmptyErrorText()}
          </Text>
        )}
        {!isValid &&
          !isEmpty && (
            <Text>
              {this.getInvalidErrorText()}
            </Text>
          )}
      </View>
    );
  }
}
(...)

As you can see, the component props interface extends the default TextInput props, which means you can pass any default TextInput prop through the component and it will be applied internally.

The value change is triggered in the onEndEditing input event → every time the user submits / ends editing the value in the current input field. This will validate and update the input as soon as the user is done entering the content. This way the validation doesn’t trigger prematurely and doesn’t give validation errors while the user isn’t finished with editing the input value.

Using the changeCallback function, the value of the input and it’s validity are propagated back to the parent component.


Now, about the custom props:

 * propName = the parent component prop name you update with the input.
 * validationType = what kind of validation type is necessary
 * changeCallback = the handler the component passes it’s internal value to
 * optional = if this is set to true, input validation is disabled. Default value = false
 * editable = “false” disables editing the value if an action is performed such as submitting data to an API
 * exists = for passing let’s say, a userExists property in case you’re checking if an e-mail is already in use. Use with e-mail validationType only.
 * minLength = minimum character length
 * compareValue = used exclusively when validationType is set to ValidationMethod.Comparable. Use to pass value to compare the input value against.
 * value = the input value passed from the parent component.
 * label = display a custom label above the input. Leaving this empty hides the label.
 * emptyErrorText = custom error text when the value is empty
 * invalidErrorText = custom error text when the value is invalid

And there you have it. You can include the ValidatedInput component anywhere and it’ll self validate every time based on the passed properties. Of course, there is room for improvement, but it’s extendable and simple to use.

Best of all, at ~250 LOC for a whole ValidatedInput component, it is a whole lot less than libraries such as informed (which can handle a lot more than this though). Still, we consider this a win.

Interested in working with us? Drop us a line at hello@prototyp.digital. We are always interested in new projects and people.

React Native self-validating input

In this step by step guide, learn about Stylelint - “A mighty, modern CSS linter” and how to make it work with both PostCSS and Visual Studio Code. 

 Quick and easy linting of PostCSS using Stylelint - Prototyped

Here at Prototyp we have a great PostCSS build internally called StartGator. It has a lot of shiny components and modules, and it has proven itself over many projects and codebases, from huge .NET solutions to one-off single page websites.

Lately, we have migrated most of our code to React with Typescript, which is a welcome change of pace in frontend development. It guides you and lints errors almost as good as backend devs have used to in their environment for quite some time. There is only one part of legacy code that is a safe-space for dead code with mixed styles — our CSS build. Until now.

Enter Stylelint — “A mighty, modern CSS linter”. There are a couple of problems we need to overcome in order to make it work with both PostCSS and Visual Studio Code, and here is the step by step guide:


Setup steps

Couple of easy steps for hassle-free CSS linting:

VS Code extensions
First, install a VS Code extension called vscode-stylelint by Shinnosuke Watanabe. There are other ways of using Stylelint, but we opted for this. You can check others in the official documentation.

PostCSS integration
VS Code needs a little help in understanding PostCSS. This is optional, but otherwise you could get a lot of nasty errors from VS Code’s side. Add VS Code extension valled vscode-postcss-language and it won’t bother you anymore.

Nice defaults
At this point, you’re actually up and rolling but it doesn’t look like much. Stylelint defaults to false for all rules so you need to provide some rules to begin with. I’d recommend another npm package called stylelint-config-recommended which enables ALL possible rules for stylelint. Add this package as a per-project dependency, or globally, whatever floats your boat. After that, you should just override rules that match your writing rules.

Configuration file
Preferred way (at least for us) for extending config is using .stylelintrc configuration file in root of your project. It makes sense as it naturally sits next to .prettierrc and any others you might have. We started with this:

{
  "extends": "stylelint-config-recommended",
  "rules": {
      "max-nesting-depth": 3,
      "property-no-vendor-prefix": true,
      "max-empty-lines": 2,
      "indentation": 4,
      "function-calc-no-unspaced-operator": true,
      "string-quotes": "double",
      "no-duplicate-selectors": true,
      "color-hex-case": "upper",
      "color-named": "never",
      "selector-max-id": 0,
      "selector-combinator-space-after": "always",
      "declaration-block-trailing-semicolon": "always",
      "declaration-colon-space-before": "never",
      "declaration-colon-space-after": "always",
      "rule-empty-line-before": "always-multi-line",
      "media-feature-range-operator-space-before": "always",
      "media-feature-range-operator-space-after": "always",
      "media-feature-parentheses-space-inside": "never",
      "media-feature-colon-space-before": "never",
      "media-feature-colon-space-after": "always"
  } 
}

All possible rules are in stylelint’s documentation.

Bonus round!
If you still happen to have errors in VS Code, open Preferences > Settings, and in User Settings add postcss file association:

"files.associations”: { 
    "*.css": "postcss" 
}

That’s it. Welcome to the well behaved, linted family. Would you do anything differently? Let me know in the comments :)

Interested in working with us? Drop us a line at hello@prototyp.digital. We are always interested in new projects.

AuthorSebastijan Dumančić

Start a Project