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 [https://www.npmjs.com/package/@prototyp/skeletor], which
is a toolkit crafted in-house at PROTOTYP [https://prototyp.digital] 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;

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

Screen Usage
Now, there is no need for extensive code to handle these elements. You can
establish complex screen layouts with a few lines
[https://www.npmjs.com/package/@prototyp/skeletor#screen] 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"];

Text Propsimport { Text } from "./Text";

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

Text UsageThis reduces the need for elaborate style sheets, enabling you to modify text
appearance [https://www.npmjs.com/package/@prototyp/skeletor#text] 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
[https://www.npmjs.com/package/@prototyp/skeletor#block], 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 Props<Block
  maxHeight="75%"
  flexDirection="row"
  align="flex-start"
  justify="space-between"
>
  ... ...
</Block>

Block UsageThis 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
[https://www.npmjs.com/package/@prototyp/skeletor#inputfocusscrollview---ios-only] 
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
[https://www.npmjs.com/package/@prototyp/skeletor#hooks] 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
[https://www.npmjs.com/package/@prototyp/skeletor#useandroidbackhandler],
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 [https://www.npmjs.com/package/@prototyp/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 [https://twitter.com/_prototyp].

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 [https://prototyp.digital/] 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.



Something like thisFeature 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
[https://github.com/joepuzzo/informed#readme] (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