Luka Buljan

Struggling with React Native's complexities? Discover Skeletor toolkit -  your key to effortless coding, quick project setups, and more.

Skeletor Toolkit: The Solution to React Native Development Challenges 

A couple of days ago we published our small in-house react-native toolkit called Skeletor. We wanted to rid ourselves of any/all growing pains you have when working on a new react-native project, whether it’s building screen layouts, handling forms, animating stuff on screen or the usual platform-specific pains:

 * Tedious project setups
 * Cumbersome layout designs
 * Repetitive boilerplate code

These things not only eat up valuable time and energy but can also be daunting for newcomers.

Our solution? Skeletor, which is a toolkit crafted in-house at PROTOTYP to cut through the noise and write less repetitive code to focus on  coding.

Did I mention that it has ZERO dependencies? Now that I did...


Here's what you get

Efficient Screen Layouts with Minimal Code

One of the first pains in a React Native project is setting up your screen layouts.

 * Skeletor's Screen component simplifies this process.

It effortlessly manages safe areas, custom backgrounds, and status bars.

/** Pass a specific background view (gradients, animated backgrounds etc) OR just a background color value. Custom components should be 100% height and width to span the full screen area. */
background?: JSX.Element | string;
hideTopSafeArea?: boolean;
hideBottomSafeArea?: boolean;
/** Set bottom safe area background color */
bottomSafeAreaColor?: string;
/** Set top safe area background color */
topSafeAreaColor?: string;
/** Set device status bar color type. */
statusBarType?: "default" | "light-content" | "dark-content";
isLandscape?: boolean;

function Component: React.FC = () => {
	return <Screen background={<GradientBackground />} statusBarType="dark-content">
	 ...
	</Screen>
}


Now, there is no need for extensive code to handle these elements. You can establish complex screen layouts with a few lines of code.

Streamlined Text Handling

Dealing with text styling can be tiring. It often requires a custom StyleSheet for each variation.

 * Skeletor addresses this through its Text component.

It allows for font name autocompletion and exposes most styling options as top-level props.

/** Inferred from @types/Font.d.ts */
font?: Font;
/** Either define [fontSize, lineHeight] or just one size applied to both fontSize and lineHeight */
size?: [number, number] | number;
textTransform?: TextStyle["textTransform"];
letterSpacing?: TextStyle["letterSpacing"];
color?: string;
textAlign?: TextStyle["textAlign"];
opacity?: TextStyle["opacity"];

import { Text } from "./Text";

function MyComponent() {
  return (
    <Text font="Arial" size={[14, 18]} color="#333" textAlign="center">
      Hello World!
    </Text>
  );
}

This reduces the need for elaborate style sheets, enabling you to modify text appearance directly and concisely within the component.

Simplified Layout Building with Block

Creating and managing layout structures is another area where Skeletor shines.

 * The Block component serves as the fundamental building block for layouts.

It offers direct control over spacing, size, alignment, and more, right in its properties.

/** Determine if Block is scrollable or not. If scrollable, extends ScrollView props. */
scrollable?: boolean;
align?: ViewStyle["alignItems"];
alignSelf?: ViewStyle["alignSelf"];
justify?: ViewStyle["justifyContent"];
flexDirection?: ViewStyle["flexDirection"];
flexWrap?: ViewStyle["flexWrap"];
flex?: number;
width?: number | string;
height?: number | string;
minHeight?: number | string;
minWidth?: number | string;
maxHeight?: number | string;
maxWidth?: number | string;
margins?: {
	marginTop?: number | string;
	marginBottom?: number | string;
	marginLeft?: number | string;
	marginRight?: number | string;
	marginHorizontal?: number | string;
	marginVertical?: number | string;
	margin?: number | string;
};
paddings?: {
	paddingTop?: number | string;
	paddingBottom?: number | string;
	paddingLeft?: number | string;
	paddingRight?: number | string;
	paddingHorizontal?: number | string;
	paddingVertical?: number | string;
	padding?: number | string;
};
border?: {
	borderWidth?: number;
	borderTopWidth?: number;
	borderBottomWidth?: number;
	borderLeftWidth?: number;
	borderRightWidth?: number;
	borderColor?: string;
	borderRadius?: number;
	borderTopLeftRadius?: number;
	borderTopRightRadius?: number;
	borderBottomLeftRadius?: number;
	borderBottomRightRadius?: number;
};

<Block
  maxHeight="75%"
  flexDirection="row"
  align="flex-start"
  justify="space-between"
>
  ... ...
</Block>

This direct manipulation of layout properties allows developers to build complex structures with straightforward, readable code.

iOS Input Focus Made Easy

A specific pain point in iOS development is managing the focus on input fields. The InputFocusScrollView component in Skeletor elegantly solves this problem. It ensures input fields are automatically scrolled into view when focused, a task that previously required third-party libraries or custom solutions. This component makes handling iOS input fields more reliable and less code-intensive.

Handling Forms and Animations with Ease

Skeletor also simplifies form management and animations. The useForm hook takes care of form states and validation, requiring only custom validation rules from the developer. This significantly reduces the lines of code needed for form handling.

Similarly, useAnimation and useAnimationTimeline hooks reduce the boilerplate code for animations, streamlining the process of creating and managing animations in your app.

Efficient Android Back Button Handling

The useAndroidBackHandler hook exemplifies the toolkit’s philosophy. It offers a straightforward way to manage the Android back button, automatically unsubscribing when not needed.

This eliminates repetitive code and ensures a smoother user experience on Android devices.

Zero Dependency: A Standalone Solution

Perhaps the most compelling aspect of Skeletor is its independence. With zero dependencies, it's built entirely with React and React Native. This means a lighter, more efficient toolkit that doesn't bloat your project with additional dependencies.

Skeletor stays true to its guiding principle: "Making your code short and to the point".

By addressing these specific React Native challenges, it not only simplifies the development process but also enhances the quality and maintainability of the code.

Check the code and examples here: https://npmjs.com/package/@prototyp/skeletor

Thank you for the time to read this! Feel free to share your thoughts about Skeletor and drop us an email at hello@prototyp.digital or shoot us a message on twitter.

Development

We made Skeletor to Simplify React Native Development

Discover all the pros and cons of developing audio playback in Progressive Web Application. 

What we learned about PWAs and audio playback - Prototyped

Not that long ago, our company was contracted to develop an application which placed a large emphasis on users being able to listen to audio podcasts while browsing the rest of the application completely uninterrupted or multitask on their devices.

The previous version of the application had a separate, hybrid mobile app that allowed users just that, but had performance and functionality issues.

Our approach was to use our React + Firebase tech stack to develop a PWA application, covering all use cases under one flexible, performant code base.


The player

We decided to present the audio player to the user at the bottom of the screen when an audio track is being played, without blocking any further interaction with other content displayed on the screen. Also, a condensed version for mobile screens is presented so that it can be expanded with a button press. A simple solution for both small and large screens.




Feature set

From a functional perspective, there were a couple of features we had to look out for, such as:

 * Switching tracks from outside the player component itself
 * Setting narration speed within the player
 * A fully functional seek/progress bar
 * The ability to download the audio source
 * Most importantly, background playback on mobile devices

Using React and Redux made most of these requirements a non-issue, with the default HTML Audio element supporting most of these controls out of the box. It didn’t take long before we had a functional component ready for testing.






Testing

The requirements to pass testing were the following:

 * Desktop versions had to be able to persist playback even when minimised in Safari, Chrome, and Firefox
 * Mobile versions had to be able to persist playback when the application is in the foreground, in the background and when the screen is locked, with basic media controls showing up on the screen when the application isn’t in the foreground.


Results



Android and desktop passed with flying colours in all cases, but iOS - not so much:

 * Worked only when the application was in the foreground.
 * When added to the home screen, audio playback stopped completely when the app was minimised or screen was locked.
 * When opened directly in the browser, audio playback persisted, but sometimes lost context and stopped playing.
 * Lock screen controls were spotty at best in both cases, sometimes showing up, sometimes not, and sometimes losing context during minimised playback (did nothing to audio playback).
 * No option to download the audio file, only open it in another tab.
 * Audio track doesn’t autoplay if there is no user action involved.






The harsh reality

As it turns out, we were fortunate to even have basic PWA functionalities. iOS 12 released a couple of days before testing with improved PWA support on iOS devices to the point that they were now usable.

Before iOS 12, PWAs didn’t persist their state — for example, with iOS 11, if a user was to browse the application, minimise it and then go back to it, the app would restart with a completely cleared cache.

The recent iOS 13 update didn’t fix any of the issues we had with iOS 12 at all, so all our hopes of Apple fixing the problem in the near future were squashed.

This presented a major problem since a large percentage of existing users had iOS devices and audio playback is a major feature to them, so Android and Desktop versions working as intended meant little at this point. Without a functioning audio player on iOS we could not ship the app. We entered limbo at this point, with all other features finished. We had to do something about it, but there was little in the way of helping us.


The next solution

The only thing left for us to try was to wrap the entire web app in a native shell and publish it on the App Store. The entire idea of having everything in one solution went flying out the window, but what can you do.

Enter Cordova.

We continued developing the solution and interoping between our web app, Cordova plugins for background playback, a separate build procedure and generally a separate project to maintain alongside the already huge PWA app.

We managed to utilise Cordova plugins and a little bit of tweaking to our audio player component to finally allow background audio playback. After a while, we had a native app to push to the store.

We tried and got rejected.

We had to implement in-app purchases to get published (because of other sections in the app allowing purchasing tickets to events). There was no efficient way to interop our React frontend with a functioning Cordova in-app purchase plugin from a technical perspective.

Exit Cordova.

At this point, we had a serious discussion on what to do next. We had to go native for iOS. It felt stupid after all this work and with Android and Desktop working perfectly, but it was the only thing to do.


The final solution

After seeing what maintaining a Cordova shell around the PWA app would look like, a native iOS application seems like a much wiser choice when considering future development.

Enter React Native, the obvious choice. We could reuse most of the functional components (entire Redux modules) from our PWA solution, which helped us immensely with a quick delivery. All we had to do was build screens and components.

It took a couple of weeks to finish development of the simplified media player app with all the audio player bells and whistles we expected to work in the PWA version in the first place. Audio download, background playback, fully functional lock screen media controls — we finally had it all.


Final word

The good thing is that audio player and PWA functionalities work perfectly fine on Android and Desktop. We built an extremely fast solution with React, Redux and Firestore that we’re very proud of. However, there are a couple of ugly aspects of it:

 * There is no control over lock screen media controls, only play and pause work.
 * An audio element has to be rendered at all times to not mess up playback permissions, no matter if there is an audio source or not. We’ve opted to use an audio object instead of an element, that is always rendered in the DOM.

Of course, the ugliest part of this is that iOS is the cause of nearly all the problems we had with audio playback and we had to build a native app to provide users the functionality Android allows from the get-go.

The worst part of the whole ordeal is that none of the issues were on our side.

Apple proved to be the blocking factor in all instances, even to the point of an application not working as intended. As to the reasons for it, we can’t be sure, but Spotify already has a pretty good idea why PWAs are discriminated against (which you can read about here: https://www.timetoplayfair.com/ ).

In the end, we lost the unified solution we wanted/the client expected and will have to maintain two solutions for the foreseeable future. Thank you, Apple.

A word of advice for any future projects involving PWA — if it has anything to do with media playback, don’t bet on iOS. Think of PWAs as ProblemsWithApple.

What we learned about PWAs and audio playback

Sebastijan Dumančić

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.

AuthorLuka Buljan

Start a Project