# RBI Tech Technical blog posts on JavaScript, React, GraphQL and friends - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Maintaining WebSocket Connections with GraphQL Subscriptions in a Serverless Environment DevFeed: [Maintaining WebSocket Connections with GraphQL Subscriptions in a Serverless Environment]() Original publisher: [Read original article]() Author: Shaila Kavrakova Published: 2021-03-31T14:49:04Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [WebSocket](), [Serverless](), [serverless architecture](), [AWS Lambda](), [Amazon API Gateway](), [GraphQL]() Tags: [amazon-api-gateway](), [apollo](), [aws](), [aws-lambda](), [graphql](), [serverless](), [serverless-architecture](), [web-applications](), [websocket]() ### AI overview This article explains how WebSockets provide persistent, bidirectional communication for real-time web applications and examines the challenge of using them with event-driven serverless architecture. It introduces AWS Lambda and Amazon API Gateway as relevant components. ### Source excerpt Maintaining a sustained connection with WebSockets and GraphQL Subscriptions in a serverless environment Photo by https://unsplash.com/@plhnk As modern technology and web applications advance, the expectation of immediate feedback and constant communication is apparent. We're accustomed to this phenomenon of instant gratification where we are fulfilled with very little or hardly any wait time at all. Just think about how we're able to receive certain packages with same day delivery. The world is at our finger tips. This continuous cause and effect cycle needs to be seamless, otherwise you run the risk of the end user becoming impatient or frustrated. WebSockets One way to achieve real time updates is through a persistent connection. This is where WebSockets come into play. A WebSocket is a transport protocol which provides a bi-directional communication channel between client and server via a sustained connection. Typical HTTP/S requests are uni-directional meaning only allowing for requests to be sent from client to server. WebSockets render polling (aka constant request/response cycles) obsolete. Once a connection is established, connection channels persist and are re-used to exchange messages back-and-forth. Some popular use cases for WebSockets are real time applications such as chat apps and multiplayer games. The server is able to push new updates without the need for frequent requests from the client. Instant gratification! Serverless Serverless architecture enables us to build and run our applications without the infrastructure overhead. When it comes to serverless, it's helpful to keep in mind that it is strictly event based. Events trigger other events. In the case of AWS Lambda, it will run our code on an as-needed basis in response to a given event. Due to this, it is not a long running process and is very transactional in nature. This brings me to the question at hand, what if we wanted to take advantage of WebSockets but with all the advantages of serv ## Keeping Form Elements Visible in Hybrid iOS Apps DevFeed: [Keeping Form Elements Visible in Hybrid iOS Apps]() Original publisher: [Read original article]() Author: Andy Weiss Published: 2021-02-28T14:19:06Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [Forms](), [Ionic](), [iOS](), [Mobile]() Tags: [android-studio](), [forms](), [hybrid-app-development](), [ionic](), [ios](), [mobile](), [simulator](), [view]() ### AI overview This tutorial examines why form elements can be covered by the soft keyboard in hybrid iOS app web views, despite behaving correctly in mobile browsers. It demonstrates a Capacitor-based hybrid app and discusses using the Capacitor keyboard API to improve iOS behavior while leaving Android unchanged. ### Source excerpt Keeping Form Elements Visible in Hybrid iOS Apps Today's mobile browsers provide a pretty great default user experience for forms. For a very simple example, visit the following url from any mobile browser: https://VisualViewport.andyweiss1982.repl.co. The user experience is great from mobile Safari. When you focus on an input field, the phone's soft keyboard animates up from the bottom of the screen. All of the content comes along for the ride, intelligently sliding up so you can see each input's value as you type. Close out the form and the viewport gracefully recedes from view. However, the same exact code can become far less elegant when consumed from a web view inside of a hybrid iOS app. Not so great inside of an iOS web view Not only do we lose the "Done" button that closes the keyboard without submitting the form; in many cases, the keyboard will pop up without displacing the form elements, covering them entirely and making the form appear completely useless! Well, It works in my web browser? 🤷♂ For reference, here is the full code for the original user experience as viewed from the mobile web: https://medium.com/media/7d7adf83c321357f9af250d2c90d1d4e/href To move this code inside of a web view, we can use Ionic's capacitor package to generate a bare-bones hybrid app that can be run in a simulator. Following the docs, you can create a new project, give it a name and assign it a directory, and then add the Android and iOS platforms. npx @capacitor/cli create? App name hybrid-forms-test ? App Package ID (in Java package format, no dashes) com.example.app ? Directory for new app hybrid-forms-test ? Which npm client would you like to use? yarnAdd platforms using "npx cap add":npx cap add android npx cap add ios For the purposes of this demo, you can just copy and paste the following code into www/index.html to generate a carbon copy of the original example into a boilerplate capacitor web view that can be run as either an iOS or Android application: https://me ## Idiomatic Alternatives to Enums in TypeScript DevFeed: [Idiomatic Alternatives to Enums in TypeScript]() Original publisher: [Read original article]() Author: Andy Weiss Published: 2021-01-31T19:19:11Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [TypeScript](), [enum](), [JavaScript](), [Programming](), [Compiler]() Tags: [compilation](), [compiler](), [enum](), [enums](), [javascript](), [programming](), [typescript]() ### AI overview This article examines TypeScript enums in relation to TypeScript's design goals and JavaScript output. It explains that enums are not merely type-level extensions, are compiled into JavaScript code, and may produce output the author considers less clean or idiomatic than expected. ### Source excerpt If you're making a list, type check it once? TypeScript is often referred to as a syntactical superset of JavaScript. In practice, this means its compiler can understand standard JS, as well as the type declarations and annotations that enable its error-detecting superpowers. For the most part, the additional syntax provided by TypeScript is stripped away during trans-compilation to JS. Indeed, its ability to gracefully disappear and produce JavaScript output that closely resembles the original code as authored is a major part of its appeal and is enshrined in the project's design goals (emphasis mine): Statically identify constructs that are likely to be errors. Provide a structuring mechanism for larger pieces of code. Impose no runtime overhead on emitted programs. Emit clean, idiomatic, recognizable JavaScript code. Produce a language that is composable and easy to reason about. Align with current and future ECMAScript proposals. Preserve runtime behavior of all JavaScript code. Avoid adding expression-level syntax. Use a consistent, fully erasable, structural type system. Be a cross-platform development tool. Do not cause substantial breaking changes from TypeScript 1.0. What, then, to make of TypeScript enums? 🤔 The idea of an enumerated type -- that a programmer can constrain the values a piece of data can hold to a pre-defined list, and be alerted when their actions diverge from their intentions -- has a rich tradition in programming going all the way back to C. Enums are native to TypeScript, but don't exist in JavaScript. But while enums are supported in TypeScript, there is no corresponding implementation in JavaScript. Worse yet, rather than disappear from the emitted JS output, they are trans-compiled into code that would be hard to refer to as clean or idiomatic. https://bit.ly/362UoxF While the function declaration and invocation above are nearly identical in TS and JS, the enum declaration trans-compiles to an IIFE with nested assignments to an object ## Working with Apollo Client Cache: Cache Keys, Invalidation, and Fetch Policies DevFeed: [Working with Apollo Client Cache: Cache Keys, Invalidation, and Fetch Policies]() Original publisher: [Read original article]() Author: Tommy Suwunrut Published: 2020-10-29T19:16:34Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [apollo-client](), [Caching](), [GraphQL](), [Front end]() Tags: [apollo](), [apollo-client](), [architecture](), [cache](), [cache-invalidation](), [caching](), [fetch](), [frontend](), [graphql](), [programming](), [react]() ### AI overview This tutorial explains how Apollo Client normalizes and stores GraphQL query results, including cache keys based on object properties and schema types. It discusses why collection queries may remain stale after server-side updates and introduces fetch policies as one way to manage cache behavior. ### Source excerpt Photo by Stephen Walker on Unsplash With its declarative fetching, helpful tooling, extensive type definitions, and built-in integration with React, Apollo Client has played a fundamental role in simplifying frontend architecture over the past few years. Its built-in caching layer, which allows you to retrieve previously requested data without needing to make additional network requests to the server, has the potential to make any application feel snappier. Apollo even provides ways of warming up the cache to be used for later, freeing our frontends from the dreaded loading spinners. But cache invalidation is one of those notoriously difficult problems in any computer program, and trying to update or bust Apollo's cache after server-side updates is far from a perfect experience, especially when the queries being cached have many filters and constraints. Let's begin with an overview of how Apollo's cache works, and then discuss the tradeoffs involved with a few different approaches to working with it. Throughout this article we'll be using this Mock List application as a reference. Cache Keys When you make any graphQL query, by default Apollo caches the response in what it calls a flat, normalized lookup table. It constructs a unique identifier for each object returned from your query, by combining its id or _id properties with the __typename defined in your schema. So if the application above executes queries as the user types "G", then "Go", then "Go g", all the way to "Go groceries shopping", Apollo could potentially pull down information about many different tasks and cache each one roughly like this: Task:1234: { name: "Go grocery shopping" } Task:2345: { name: "Go to gym" } Task:3456: { name: "Learn GoLang" } This is great if the user navigates to a detail view about a given task, because there will already be some data immediately available. Apollo will also store the results of each of those individual queries, in case you make the same exact query again late ## 30 Keyboard Shortcuts to Turbocharge Your Team's Engineering Velocity DevFeed: [30 Keyboard Shortcuts to Turbocharge Your Team's Engineering Velocity]() Original publisher: [Read original article]() Author: Mitch Posk Published: 2020-09-30T01:45:26Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [Development](), [Visual Studio Code](), [navigation](), [coding]() Tags: [editor](), [keyboard](), [search](), [shortcut-keys](), [shortcuts](), [software-development](), [terminal](), [visual-studio-code](), [web-development]() ### AI overview A tutorial presents keyboard shortcuts intended to help developers work more efficiently. The supplied excerpt focuses on Visual Studio Code navigation, including sidebar, file explorer, search, source control, debugger, extensions, terminal, project search, and filename search shortcuts. ### Source excerpt Photo by SpaceX on Unsplash Every developer knows a shortcut or two that makes the job just a little bit easier. While those new to the industry might dream of a time in the far-off future when their fingers are the limiting factor to their coding output, a seasoned veteran can light up a keyboard like a jazz musician improvising over a familiar melody. I've overheard engineers let out an audible gasp the first time they see a coworker lay down a novel key combination. The look on their face tells the entire story: Just think of how much time we could have saved! If only I'd known! Shortcuts allow us to spend more time focusing on the important aspects of software engineering -- and over the span of a career spent largely in front of a keyboard, they compound to save us hours, days, or even weeks of development time. When widely used across an engineering team, shortcuts can significantly increase engineering velocity and output. And yet, our tendency as developers is often to hoard them, holding them close like competing magicians guarding the secrets behind our sleight of hand. The goal of today's post is to pull back this curtain, and divulge a few favorite tricks of the trade. Now that we are less likely to be sharing the same physical space and picking up new techniques through office osmosis, I believe we have to become more explicit in sharing what works for us with our team mates. What follows are my most-used shortcuts that save me the most time. My hope is that you will find a few of them new and useful, and adopt them into your own repertoire. Visual Studio Code Navigation cmd + b is a shortcut to open or close the workbench sidebar. We do this about a million times a day, so the time it saves can add up quickly. But not only can we do it faster, we can do it better, too! By moving the sidebar to the right, you can keep your code from jumping all over the screen when it opens, and therefore maintain better flow and focus. Text remains in place with the Sid ## Manipulating Screen Brightness on iOS and Android with Ionic React DevFeed: [Manipulating Screen Brightness on iOS and Android with Ionic React]() Original publisher: [Read original article]() Author: Alejandra Del Valle Published: 2020-08-20T19:06:20Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [Ionic](), [React](), [React Hooks](), [Android](), [iOS](), [PWA](), [Web Components](), [Development]() Tags: [android](), [components](), [development](), [how-to](), [ionic](), [ios](), [mobile-app-development](), [pwa](), [react](), [react-hooks]() ### AI overview This tutorial discusses controlling screen brightness on iOS and Android using Ionic React and Ionic React Hooks, including the package's Capacitor API wrappers and support for shared-codebase applications across mobile, desktop, and PWA targets. ### Source excerpt Manipulating Screen Brightness on iOS and Android Devices Undoubtedly one of the most annoying side effects our phones have is its ability to change screen brightness dynamically. Whether it's a setting enabled on your device to automatically adjust brightness based on your environment, or an app you downloaded manipulates it based on its needs, sometimes it's just out of your control. Maybe you're an avid digital content creator and having your screen brightness at its max is to help your content be "pixel-perfect" and edited just the way you want. Maybe you're visiting a store and need to scan your screen to quickly and easily pay for something without fumbling through your wallet or purse. Or, maybe you're at a show or at home for a movie night and having your screen brightness as low as possible is important to one, not blind you, and two, not blind your neighbors. Whatever the backstory, it's important for the apps we use to consider how we use our phones in our day-to-day lives to create a seamless experience that users will enjoy. Let's look at how we can help with this experience in native development using Ionic React with Ionic React Hooks (recently renamed to React Hooks for Capacitor). Keep reading if you have basic experience with React and React Hooks. If not, I would suggest getting familiar with React and then hop back on over! Why Ionic React? Short answer? Ionic React is ultimately just... React. Music to my ears. Ionic React is also built using web components, making it compatible with a multitude of web libraries and supports iOS, Android, Desktop, and PWA (i.e. progressive web apps) all by using one shared codebase (I'm hearing music again...). Ionic React Hooks Re-introduced Ionic announced their launch of Ionic React Hooks back in December of 2019. It has recently been renamed and moved to the Capacitor Community org -- @capacitor-community/react-hooks. This package provides a collection of wrappers around Capacitor APIs along with a few other Ioni ## Theme with styled-components and Typescript DevFeed: [Theme with styled-components and Typescript]() Original publisher: [Read original article]() Author: Ethan Nguyen Published: 2020-07-14T12:58:19Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [styled-components](), [TypeScript](), [CSS](), [Design system](), [modern web development]() Tags: [css](), [dark-mode](), [design-system](), [design-systems](), [how-to](), [javascript](), [styled-components](), [themes](), [typescript](), [visual-studio-code]() ### AI overview A tutorial on theming applications with styled-components and TypeScript. It covers installation, Visual Studio Code support, declaration files, theme interfaces, naming conventions, theme creation, ThemeProvider setup, and switching between themes. ### Source excerpt What is styled-components? Styled-components is arguably the most common CSS-in-JS library out there (Don't trust me? Check out their site and their adoption from many organizations, 7.6M/month downloads on NPM 🔥). One of its advanced use cases for this library is theming. Theming in styled-components allows your app to support multiple design patterns within the same app. Imagine an amazing code editor with no dark mode! Having options to customize the look and feel of your app from the primary colour palette to the typography scale can help our system to capture more personas. This article will give some breakdown of the basic setup and naming convention for theming your app with styled-components, and how to setup Typescript with styled-components themes Installationyarn add styled-components yarn add @types/styled-components -DVSCode plugin If you are using Visual Studio Code, I highly recommend installing this helpful plugin. It will highlight and IntelliSense your syntax for styled-components Create a declaration file Firstly, we will need to define how our theme interface looks like. Inside src folder, create styled.d.ts file and extend the existing styled-component DefaultTheme. This will help with IntelliSense and ensure a contract for all available themes. // styled.d.ts import 'styled-components';interface IPalette { main: string contrastText: string }declare module 'styled-components' { export interface DefaultTheme { borderRadius: string palette: { common: { black: string white: string } primary: IPalette secondary: IPalette } } }Naming convention Let's break down some logic here for the naming convention of theming. As I mentioned earlier, our goal for theming a system is to be able to control the compactness and colour palette. Hence we should define our theme around these styles like border-radius font-weight font-size ... and all colour related. About colour naming, avoid naming variable with actual colour but do name with something likeprimary or sec ## A/B Tested, Feature Flagged, White-Label Apps with Webpack DevFeed: [A/B Tested, Feature Flagged, White-Label Apps with Webpack]() Original publisher: [Read original article]() Author: Andy Weiss Published: 2020-06-17T19:15:05Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [Webpack](), [React](), [configuration](), [import](), [App]() Tags: [a-b-testing](), [configuration](), [feature-flagging](), [import](), [react](), [webpack]() ### AI overview This tutorial explains how to customize Webpack in a Create React App project to build and deploy multiple application variants from one codebase. It discusses use cases including A/B testing, feature flagging, platform targeting, and custom themes, with attention to file-extension resolution and import behavior. ### Source excerpt For most of us, the thought of tweaking our app's Webpack configuration inspires about the same level of excitement as a bi-annual trip to the dentist. We know it's important, necessary even -- certainly better than the alternative -- and yet, the goal is mostly to get in and out without anything going wrong. The popularity of Create React App and other tools is largely built upon their ability to abstract away these configuration details and allow developers to focus on shipping features quickly. But the better we know our tools, the more likely we are to recognize when they fit a particular problem we face in our work. For a certain class of project, it's worth considering Create React App's defaults as a starting point, rather than the end of the conversation. Thoughtfully applied, some small modifications can unlock a world of possibility. For example, we often know at the outset of a project that we will need to build and deploy different versions of our application. Whether it's for A/B testing, feature flagging, targeting specific platforms, or applying a custom theme, we want the ability to maintain multiple parallel universes around a single codebase without unnecessary duplication or complexity. Webpack's ability to select from a variety of file extensions at build time makes it an especially useful tool for this task. You'd probably be surprised to see how just easy it is to achieve a high level of flexibility with minimal configuration. More Intentional File Extensions Part of Webpack's magic comes from its ability to guess our intentions when we leave off the file extension at the end of an import. We do it so often we may barely notice, but how many times have we written code like this? https://medium.com/media/2f79921db578db57aa03929c826ccb82/href Maybe there's a Nav.js file in the components directory, or possibly the extension is .jsx or .tsx. Maybe Nav is actually a directory itself, and there's an index.js or index.jsx that's exporting the component ## Safari's 100vh Problem DevFeed: [Safari's 100vh Problem]() Original publisher: [Read original article]() Author: Jon Rose Published: 2020-06-17T19:14:35Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [CSS](), [iOS](), [JavaScript](), [Web Development]() Tags: [100vh](), [blog-post](), [css](), [css3](), [ios](), [javascript](), [safari]() ### AI overview This tutorial explains how Safari on mobile handles the CSS 100vh unit. Safari keeps the viewport height constant while its button bar hides and reappears, which can cover content or navigation. The article recommends positioning for navigation and using JavaScript with innerHeight when content height must reflect the visible viewport. ### Source excerpt Safari, being an Apple product, tends to "Think Different". Given Apple's dominant market share, especially in the US, it's important that we understand these differences, and know how to work with them. In this blog post, we're going to tackle the 100vh problem. 100vh Quick recap. The vh unit, introduced with CSS3, allows you to specify the percent of the total viewport's height. So 100vh would be 100% of the viewport. It's mobile responsive and has made building layouts much easier. Navbar Problem Let's try making a simple homepage with a footer for navigation. https://medium.com/media/cff698e095a28a6928ff7148fc3c694d/href In the main element is our content. We give it a height of 95vh or 95% of the total height. The footer gets the remaining 5% of the viewport. If we load this up on a desktop, it works exactly as expected. Checking Safari on mobile and we see: Why? This must be a bug, right? Well, no. This is actually a feature. When working on Safari, the team worked hard to show the button bar only when necessary. Their goal was to give more space to the website whenever possible, which is why the button bar hides when scrolling. This lead to a tough decision about how the viewport's height would be handled. Would it: 1. change the height every time the bar hides and shows or 2. make the viewport height constant, and have the button bar cover part of the viewport They opted for a constant height to avoid jankiness. This means that our navbar is in fact there, just hidden behind the button bar. When the button bar hides, we can see the navbar really was there. Navbar Solution So what do we do? Instead of placing our navbar by using height, we use positioning instead. https://medium.com/media/20c4987011013a9c0c01fd1b0ce9aceb/href Checking it out on desktop and we can see nothing changed: And now on mobile, we finally get what we expect. Content Problem The navbar example is a bit contrived. Hopefully you wouldn't use height for positioning regardless of the 100vh ## Wrangling Wild CMS Data with TypeScript DevFeed: [Wrangling Wild CMS Data with TypeScript]() Original publisher: [Read original article]() Author: Pedro De Ona Published: 2020-06-17T19:13:47Z Content type: tutorial Language: en Sources: [RBI Tech]() Topics: [Content Management System](), [TypeScript](), [GraphQL](), [Developer experience]() Tags: [cms](), [code](), [developer-experience](), [graphql](), [typescript]() ### AI overview This developer article explains how RBI handles unpredictable, human-edited CMS data in real time. It discusses using TypeScript and GraphQL to improve confidence in shipped features and introduces optional chaining and utility types to reduce unexpected type errors when working with CMS-derived data. ### Source excerpt Attempting to get the CMS under control Here at RBI, we've prioritized building a software platform that enables us to rapidly deliver high value. Sometimes this means literally delivering valuable food to your waiting stomachs, but for software engineers, it also means delivering a highly customizable web platform to our internal marketing teams, which allows us to drive dynamic customer experiences with minimal engineering effort. To that end, one of the products that we incorporate in our tech stack is a CMS. Classic Three-letter Acronym A CMS, or content management system, can be used in a variety of ways. At RBI we primarily use it to allow our digital marketing and product teams to control the content we deliver on our websites in real-time. This can be both a boon and a curse. On the one hand, it enables us to curate and create new experiences without needing to wait for deployment, but on the other, it means our code needs to be prepared to deal with some pretty unpredictable data. Oftentimes, this data is simply used to control the display of content to the user, but we also use it to drive some pretty core functionality like our digital menu, and this is where things can become problematic. CMS data is edited by humans and published in real-time, which means null or missing values in data are an unfortunate reality, and if not dealt with proactively, can lead to production failures. To that end, we rely on TypeScript and GraphQL as two technologies that increase our confidence in the features we ship. These tools can work hand-in-hand to create an excellent developer experience and help ensure you are writing sound and correct code. They Can, But Do They? That being said, sometimes the harsh reality of typed code can be more of a thorn in one's side than a brilliant shining beacon, guiding you to feature completion. Take the following interface, derived automatically from a GraphQL operation, as an example: https://medium.com/media/a0635a0c94916a7504311adc