EMIKETIC

React Native Continuous Delivery with GitLab CI/CD and Appetize

Fri, 14 Sep 2018 01:00:00 +0100

At EMIKETIC, it is important for us to provide results as fast as possible and in a convenient and easy-to-use format.

Also as a service company, we’re required to swiftly validate changes by fellow developers, QA officers, and/or clients.

Automated and continuous delivery is therefore a critical process for us. It is very feasible for web apps, but might be more challenging for mobile apps.

Our Approach to CI/CD

On most of our projects, our current approach to automated delivery is as follows:

Use GitLab CI/CD, a powerful continuous integration/delivery engine, to validate, test, build, and deploy any changes committed to codebase.
Use Appetize, an “online web based iOS Simulators and Android Emulators”, to demonstrate changes within the comfort of web browser.
Provide a link to downloadable build for users to install and run on their devices.

This approach is better demonstrated by our React Native Starter , our de facto boilerplate for modular and robust React Native app.

GitLab CI/CD

GitLab CI/CD is probably one of most capable CI/CD engines out there, an it is a personal favorite.

We use GitLab CI/CD descriptor (.gitlab-ci.yml) combined with a number of custom scripts and Docker images. The resulting flow looks like follows:

Having your code at GitLab is not a requirement since it is possible to mirror repository from other sources.

Appetize

Appetize is very convenient tool for actually running a mobile application without having to install it on a device. It supports multiple iOS and Android devices and versions.

We use Appetize’ HTTP API to automatically upload available builds. This is done mainly the following command:

curl "https://${APPETIZE_TOKEN}@api.appetize.io/v1/apps/${APPETIZE_ID}" -F "file=@${TARGET}" -F "platform=${PLATFORM}" -F "note=${CI_COMMIT_SHA}"

Where CI_COMMIT_SHA is a git commit reference provided by GitLab CI/CD.

Downloadable Build

Providing the ability to download and install the app enables involved parties to properly validate the application in real world usage. For now, this is only possible for Android (APK).

To accomplish this requirement, we use a simplistic solution which is a shared hosting that we upload builds to using FTP, mainly with following command:

curl -u "${FTP_USERNAME}:${FTP_PASSWORD}" "ftp://${FTP_DOMAIN}${FTP_PATH}/${CI_COMMIT_REF_SLUG}/" -T $TARGET

Where CI_COMMIT_REF_SLUG is a git reference (tag or branch) provided by GitLab CI/CD.

This solution is good enough for us even when security/access is a constraint (we use .htaccess).

For more fine-grained control, we’re looking into Google Drive among other suitable candidates like Dropbox, Amazon S3, …

What’s next?

Continuous delivery is not complete while actual production build and deployment to stores remain manual. To accomplish this we’re looking into fastlane .. a subject for another blog post.

Remote is the new cool: Le télétravail au quotidien

Tue, 29 May 2018 15:36:00 +0100

Ne soyons pas has been : Travailler en remote, ou télétravail, n’est plus une question d’innovation ou de résolution de contraintes géographiques.

Ayant débuté comme un mouvement millenial, ensuite nomad, aujourd’hui le remote est une norme bien établie aussi bien dans le monde du tech que d’autres domaines variés tels que la création ou les NGOs.

Cet article reprend quelques éléments de réflexion sur notre expérience avec le remote. Il s’agit d’un article avec des opinions assez engagées sur le sujet du remote et la façon d’organiser une équipe de concepteurs logiciels en général.

Contexte

EMIKETIC est aujourd’hui une équipe d’une dizaine de personnes réellement semi-remote. Par choix ou par convenance, la moitié de notre staff dont 2 team-leads et un account manager, travaillent de chez eux en quasi full-time. Tout en étant le dirigeant de la compagnie, je travaille moi-même souvent jusqu’à une semaine par mois depuis la maison. Et nous continuons à ouvrir des postes en remote ou in-office au choix de chacun.

Pour vous dire à quel point nous aimons et croyons au remote.

Question à l’envers : Pourquoi un bureau ?

Chez EMIKETIC, nous tâchons d’avoir une culture de la réflexion bien forgée autour de la remise en question des idées préconçues, critiques et arguments à l’appui. A chaque devrait nous ripostons avec un pourquoi.

Quand on y pense, pourquoi est-ce qu’une équipe de créateurs de logiciels doit-elle se retrouver dans un espace physique pour accomplir un travail qui est intrinsèquement de nature virtuelle ?

La ponctualité est dans l’efficience et l’efficacité

Contraintes de ponctualité d’horaire de travail, pointage, comptabilité d’heures, obligation de présence sont tous des symptômes d’une organisation avec une culture défaillante ou absente, une crise de confiance et des process battis sur la quête illusoire du contrôle.

Cette affirmation est bien entendue formulée dans le cadre d’une agence d’activité et taille similaires aux notre. Mais il est assez simple de tirer le même constat pour des organisations de taille bien plus grande. La littérature et l’industrie regorgent d’exemples full-remote de compagnies dans les TIC (et autres activités) de grande, voire très grandes tailles à l’instar de Hubstaff, qui ne cherchent pas nécessairement à exercer le contrôle.

Les process sont et doivent toujours être de mise, mais cibler ponctuellement les vrais pain-points d’une équipe logicielle : L’efficience et l’efficacité

L’effort avant le temps

Toujours dans le même sillage, il est préférable de réfléchir en termes d’effort que de temps. Il s’agit d’ailleurs d’une nuance fondamentale dans la méthodologie Agile. Cela ne veut pas dire qu’il ne faut pas comptabiliser le temps. Mais cela doit émaner d’une volonté opérationnelle de mieux exécuter un projet, améliorer un process ou prévenir des saturations de planning des équipes de développements. C’est d’ailleurs l’une des raisons pour laquelle nous avons récemment investi dans la suite Harvest et Forecast (ceci sera le sujet d’un autre article sur la planification)

Le temps est un outil essentiel pour optimiser la rentabilité. Nous vendons du temps, et nous réalisons des bénéfices quand le temps est amoindri par l’efficience de nos développeurs. Tenter de contrôler leur temps afin d’être aligné avec une norme autoproclamée dont personne ne connaît ni la raison, ni l’auteur, ni l’origine, revient à courir après des moulins à vent.

Optimisons l’efficience, afin que l’effort compresse le temps.

L’engagement n’est pas physique mais intellectuel

Un manque de commitment, ou d’engagement (à différentier de motivation), d’un collaborateur est un mal déjà installé, voir propagé au reste de l’équipe. Le fait que la personne soit présente dans un bureau, dans la même salle que son manage, ou même avec 360 caméras de surveillance n’y changera rien.

Ce n’est pas parce qu’une personne se présente tous les jours à l’heure tout en étant assidue et appliquée au travail qu’elle délivrera. La fameuse delivery est un cocktail, souvent corrélé à l’engagement, qui provient de la culuminance de toute une combinaison d’ingrédients bien maturés dans le temps et qui n’ont rien à voir avec la présence au dans un site physique corporatif :

Le bon recrutement
Un onboarding réussi
Une formation adaptée
Processus conçus pour standardiser, accompagner et protéger
Une culture et un ADN
… etc.

L’art de se réunir

Similairement à un effort de développement, une réunion doit avoir une allocation de ressources, un but (généralement un problème à résoudre), un chiffrage et un résultat. sinon elle n’a pas lieu d’être.

Tout l’arsenal technologique d’une entreprise en ingénierie logicielle doit être dédié à une seule et unique cause : Minimiser la distraction d’un développeur et minimiser le temps de réunions. Parmi ces outils citons :

Slack, Stride ou Hangouts sont d’excellents outils pour communiquer en différé. C’est à dire que le destinataire peut répondre à une question quand il en a le temps ou l’envie.
Les pull-requests sont un moyen efficace pour discuter du code. Ils forcent les protagonistes à être spécifiques et cadrés à un feature, bug-fix ou tâche donnée dans leur discussion.
Les issue trackers tels que JIRA ou Trello permettent de prioriser un plan d’action (un sprint), donner son avis sur comment et quand on devrait s’y prendre

Chez EMIKETIC, nous avons banni la réunionite très tôt, dès l’aube de la compagnie. Notre approche aux réunions internes est simple :

En cas d’interrogation : Faire ses devoirs et ses recherches. Si pas clair => Écrire sur un canal Slack public pour bénéficier (et faire bénéficier) du savoir de tous. On vous répondra en fonction de l’urgence et de la pertinence de votre question.
En cas de volonté de connaître l’état d’un projet (un besoin de manager bien souvent) : Lire et comprendre ce qui se passe sur le issue tracker ou le repo.
Si toujours bloqué pour un des points précédents => planifier une réunion envoyer une invitation Google Calendar avec un lien pour un call.
Si vraiment, vraiment urgent et bloqué (très rare) => Proposer une réunion physique. Mais elle doit vraiment en valoir la peine :)

Toujours convaincu qu’un bureau est nécessaire pour faire des réunions ? :)

Le remote : Un filtre clientèle naturel

Un argument qu’on entend souvent, est qu’un bureau est nécessaire pour accueillir des clients. La réponse est bien entendu oui. Plusieurs clients demandent à organiser les premières réunions au bureau afin de s’assurer que l’entreprise n’est pas un garage one-man-show. Cependant, nous avons remarqué par expérience que ce genre de clients n’apportaient pas réellement de la valeur ajoutée. Il faut choisir ses clients. Cela est d’autant plus vrai pour une équipe logicielle professionnelle en Tunisie, où nous vendons des denrées rares : Le temps et la qualité. On appelle cela un positionnement

Les bons clients, qui sont à la recherche d’une collaboration durable et un service de qualité n’accordent généralement pas d’attention à des détails extérieurs tels que la localisation ou la décoration du bureau. Ce qu’ils cherchent c’est avant tout des garanties de délais et de delivery. Pensez-vous que des collaborateurs présents dans un bureau est un gage de qualité et de delivery ?

Par ailleurs, étant dans une industrie fortement internationale, et de notre perspective Tunisienne axée sur l’exportation, les clients internationaux sont eux même généralement une clientèle remote habituée à commander et superviser à distance.

Dirigeants : Vos clients ne se déplaceront pas pour vous par avion. Pourquoi feriez-vous déplacer vos collaborateurs pour un client qu’ils pourront servir de chez eux avec les mêmes outils qu’au bureau ?

Un bureau est un point de rassemblement

Ce qui est défendu dans cet article, est un appel à repenser le bureau et non à l’aliéner. Travailler en remote ou in-office doit être une option à la discrétion de chaque collaborateur.

Nous avons par exemple au sein de l’équipe EMIKETIC, aussi bien des mères de familles souhaitant rester proches de leurs enfants, que d’autres mères souhaitant se donner un espace de liberté vis-à-vis de leur vie familiale. Ce sont des choix personnels que toute entreprise moderne se doit de respecter et accommoder au maximum.

Nous vous invitons d’ailleurs à lire le témoignage personnel de Bakhta Bonnet, notre account manager (poste frontal vis à vis des clients) sur le travail en remote en tant que maman.

Nous voyons aussi un bureau comme un espace de conférence. On s’y retrouve pour discuter, échanger, socialiser et expérimenter ensemble de manière ponctuelle et périodique. A titre d’exemple, la politique remote actuelle d’EMIKETIC stipule que chaque collaborateur remote se doit d’être présent une journée par semaine au siège de Nabeul, afin de perpétuer ce rituel.

Conclusion

Il n’y a pas d’autres conclusions que Remote is the new cool :) Nous espérons que vous avez aimé l’article et que cela vous incite à postuler chez EMIKETIC ou simplement partager votre avis avec nous.

N’hésitez pas à nous contacter via le site web ou notre page Facebook

SendBird for building React Native messaging apps

Mon, 02 Apr 2018 19:48:00 +0100

Sending messages with apps has become a worldwide top use on mobile devices and messaging applications have become more ubiquitous.

In this blog post, we will share with you our experience with messaging applications built with React Native. It is worth mentioning this article is based on a real-life example for a client application we built at EMIKETIC.

Messaging is no longer a medium nor just a feature. It’s a realm for large tech companies that center their business case around messaging. Yet it still does beg the question: Shall I build my own feature, in-house development or integrate a 3rd party solution?

Generally, teams prefer to use an off-the-shelf messaging SDK solution. It’s the best way to reduce time-consuming efforts, increase performance and focus on the core content. This is why we opted for SendBird, which we believe is among the best messaging SDKs for React Native applications. The SendBird back-end is really a scalable, powerful and comes with a fully-documented chat API. SendBird makes integrating real-time chat to any (React Native) app as easy as pie.

SendBird features two fundamental family of APIs: Client APIs (including the React Native one), and a Platform API. The Platform API, which we will not cover in this article, allows to communicate with the SendBird back-end from our own back-end or server application (server to server communication), which is extremely handy if you want to trigger actions from your Rails, Meteor or Node app based on an event. Typical scenarios include push notifications or activity online/offline status update in the UI. For now, let’s discover the amazing client API step by step.

We’ll build a simple messaging app using React Native with SendBird’s JavaScript SDK.

First, you’ll need to create a new SendBird application in the SendBird console.

Installation

In your React Native project folder, you need to run

npm install sendbird --save

Connect to SendBird

SendBird requires a UserID to connect or to create a new user account. The UserID can be any unique id, such as an email address or a database UID.

We do not need a separate registration process. SendBird creates for you a new account if you have not been registered yet, all you need is to specify your unique ID.

The first thing we’re going to need is a screen where the user can enter a userID and a nickname they want to appear as.

Let’s start creating a Sign in screen:

import React, { Component } from 'react';

import { Container, Content, Item, Input, Form, Button, Label, Text } from 'native-base';

type Props = {};

export default class LoginScreen extends Component<Props> {
  state = {
    email: '',
    nickname: '',
  };
  render() {
    return (
      <Container>
        <Content>
          <Form style={{ padding: 16 }}>
            <Input
              onChangeText={email => this.setState({ email })}
              placeholder="email"
              style={{ backgroundColor: '#fff', marginVertical: 16 }}
            />
            <Input
              placeholder="nickname"
              onChangeText={nickname => this.setState({ nickname })}
              style={{ backgroundColor: '#fff', marginVertical: 16 }}
            />
            <Button full onPress={this._connect(this.state.email, this.state.nickname)}>
              <Text>Connect</Text>
            </Button>
          </Form>
        </Content>
      </Container>
    );
  }
}

In this tutorial, we will use email as UserID and nickname to be displayed beside each message we send.

First, we have to import sendbird to our component:

import SendBird from 'sendbird';

Next, we should initialize SendBird using the APP_ID assigned to our SendBird application.

const sb = new SendBird({ appId: APP_ID });

Let’s write our first function using the SendBird functions connect() and updateCurrentUserInfo():

connect(): This is for sending a connection request and also used to create a new user account if the user has not been registered yet.
updateCurrentUserInfo(): A function called to update user’s nickname and profile image.

import SendBird from 'sendbird';

const sb = new SendBird({ appId: APP_ID });
// some code
export default class LoginScreen extends Component<Props> {
  // some code
 _connect(email, nickname) {
   const self =  this;
   sb.connect(userId, (user, error) => {
       if (error) {
           console.log('SendBird Login Failed.');
       } else {
           sb.updateCurrentUserInfo(nickname, null, (user, error) => {
               if (error) {
                   console.log('Update user Failed!');
               } else {
                 self.props.navigation.navigate('Home');
               }
           })
       }
   });
 }
 render() {
   return(
     // some code
   );
 }
}

connect() Should be returning a plain JavaScript object describing the user profile.

We are registered now! Let’s move on to the next step.

Join channel

All regisetred users can create or join channel which provides methods to easily send, fetch, and receive messages in real-time.

SendBird provides you with different types of channel:

Open channel: Anyone may join and participate in the chat.
Group channel: The user can join the chat only through an invitation. It could be a private channel among multiple users or between two users. Also, You can send files and custom data using files transfers.

In our app we will use a group channel.

import React, { Component } from 'react';

import { Container, Content, Text, Right, Body, Header, ListItem, List, Left, Thumbnail, Button } from 'native-base';

type Props = {};
export default class HomeScreen extends Component<Props> {
  render() {
    return (
      <Container>
        <Content>
          <List style={{ padding: 16 }}>
            {users.map(user => (
              <ListItem avatar key={user.id} style={{ padding: 16 }}>
                <Left>
                  <Thumbnail source={{ uri: user.profileUrl }} />
                </Left>
                <Body>
                  <Text>{user.name}</Text>
                  <Text note>Online</Text>
                </Body>
                <Button transparent onPress={() => this._joinChannel(user.userId)}>
                  <Text>chat</Text>
                </Button>
              </ListItem>
            ))}
          </List>
        </Content>
      </Container>
    );
  }
}

Here we listed some users which are already registered.

Let’s define our function joinChannel() in order to create a channel with two members (1-to-1 messaging).

 _joinChannel(receiverId) {
    const sb = SendBird.getInstance();
    const self = this;
    sb.GroupChannel.createChannelWithUserIds([receiverId],
      true, (createdChannel, error) => {
        if (error) {
          console.error(error);
        } else {
          self.props.navigation.navigate('Chat', { channel: createdChannel });
        }
    });
  }

createChannelWithUserIds(): This function is called to create a new channel. You should pass two user IDs or your opponent ID. It aims at returning a plain JavaScript object describing the channel.

The best part about this is that you can pass information by passing additional arguments such as name, coverUrl, data, customType…

See SendBird Docs for more informations.

Let’s chat!

Now for the main dish, we’re going to create our chat room.

As a first step, we need to create a chat UI component.

In general, we can create our own chat UI our selves using simply React Native library. There are also several libraries dedicated to this matter. For example here, we used react-native-gifted-chat. While using this library can be useful, it may come with its own burden of integration and customization issues (feel free exploring the not-so-maintained source code behind it :) ).

import React, { Component } from 'react';
import { View } from 'react-native';
import { Container } from 'native-base';
import { GiftedChat, Bubble, LoadEarlier } from 'react-native-gifted-chat';
import SendBird from 'sendbird';

import styles from './chatScreen.css';

type Props = {};
export default class ChatScreen extends Component<Props> {
  state = {
    messages: [],
  };
  render() {
    const bubble = props => <Bubble {...props} wrapperStyle={styles.wrapperStyles} />;
    const composer = props => <Composer {...props} multiline textInputStyle={styles.composerStyles} />;
    const loadEarlier = props => {
      if (_.isEmpty(this.state.messages)) {
        return <LoadEarlier {...props} label="Start a conversation" />;
      }
      return null;
    };
    return (
      <Container>
        <GiftedChat
          messages={this.state.messages}
          renderBubble={bubble}
          loadEarlier
          renderLoadEarlier={loadEarlier}
          isAnimated
          keyboardShouldPersistTaps="never"
          onSend={messages => this.onSend(messages)}
          user={{
            _id: currentUser.userId,
            avatar: currentUser.avatar,
          }}
          showUserAvatar
        />
      </Container>
    );
  }
}

Our chat UI component is ready now!

At this stage, we are ready to send messages and load created conversations.

Let’s send our first message!

SendBird SDK provides you with methods to send messages in an entered channel such as sendUserMessage() and sendFileMessage().

sendUserMessage(): Used to send text messages.
sendFileMessage(): Used to send binary messages.

onSend(messages = []) {
  const handle = this;
  const sb  = SendBird.getInstance();
  const channel =  this.props.state.params.channel;
  this.setState((previousState) => {
    channel.sendUserMessage(messages[0].text, (response, error) => {
      if (!error) {
        // handle.getChannelMetaData(channel);
      }
    });
    return { messages: GiftedChat.append(previousState.messages, messages) };
  });
}

You could load a conversation by creating a query using createPreviousMessageListQuery(), this instance loads the most recent n messages.

Note: n is a fixed number used to query a set of n number of previous messages.

import React, { Component } from 'react';

import { Container } from 'native-base';

import SendBird from 'sendbird';

type Props = {};

export default class ChatScreen extends Component<Props> {
  state= {
     messages: [],
  }
  componentDidMount(){
    const { channel }  = this.props.navigation.state.params;
    this.getChannelMetaData(channel);
  }
  getChannelMetaData(channel) {
    if (channel) {
      const self = this;
      const messagesQuery = channel.createPreviousMessageListQuery();

      messagesQuery.load(50, true, (messages, error) => {
        if (error) {
          console.error(error);
        }
        this.setState({
          messages,
        });
      });
    }
    return;
  }
  render() {
    return (
      //some code
    );
  }
}

By providing its own event handlers, the SendBird SDK allows you to track events occurring within channels or devices such as typing, read receipts and more. It is highly advisable you walk the extra mile and discover what this rich SDK has to offer yet.

Learn more about SendBird Event Handler.

Conclusion

This post guides you through the preliminary steps of setting up SendBird in your own React Native app. I hope you found this article useful to kick off learning how to add real-time chat to your React Native app with speed and efficiency.

Feel free reaching out to us should you have any questions regarding the examples and code snippets above. I will try to share with you the sample project behind it shortly.

On a final note, keep in mind that if you have a super robust SDK, you don’t need to reinvent the wheel!

Server Side Pagination, using React, Redux and Ant Design

Tue, 27 Feb 2018 12:20:00 +0100

Let’s be straightforward: Fetching a quite long list of users (or other entity) from an API and displaying them in a list view is relatively not useful especially for large sets of data.

The main handicap of this idea would be an unlimited scroll down list which is definitely a bad design. Plus sinking the client with data.

Server side pagination seems useful to solve this matter. It transfers to the client a much smaller data to handle. So it provides the possibility to specify the number of data sub-sets to retrieve per page and for a given page number.

Although a substantial number of APIs do support serving data in this fashion, there are also a considerable number of them that don’t.

In our blog post, we are exposing two different solutions :

Server side pagination assuming an API that supports it.
Client side pagination without pagination, that is full data transfer.

At EMIKETIC, we use React with the Redux architecture combined with Ant Design. We will be showcasing this post with this stack along with a example loading users from a Restful API.

Let’s dive in!

As the Redux mantra prescribes it, all the application state is stored as a single object in a store. First of all, let’s define a sub-state we will call User ( refers to user component) in order to store rendered data and pagination states.

User component substate

const INDEX_PAGE_SIZE_DEFAULT = 50;
const INDEX_PAGE_SIZE_OPTIONS = [5, 10, 20, 30, 50, 100];

state = {
  data: null,
  meta: {
    page: 1,
    pageSize: INDEX_PAGE_SIZE_DEFAULT,
    pageSizeOptions: INDEX_PAGE_SIZE_OPTIONS,
    pageTotal: 1,
    total: 0,
  },
};

First Approach: Server-side pagination

This approach is used only when the API supports sending pagination parameters to receive a much smaller amount of data. Using Redux, we have to define action types, action creators and thunks to make it all happen.

Action Types and Action Creators to load users

// REQUEST LOADING USERS
const USER_INDEX_REQUEST = 'USER_INDEX_REQUEST';
const fetchIndexRequest = () => {
  return {
    type: USER_INDEX_REQUEST,
  };
};

// USERS RETREIVED WITH SUCCESS
const USER_INDEX_SUCCESS = 'USER_INDEX_SUCCESS';
const fetchIndexSuccess = payload => {
  return {
    type: USER_INDEX_SUCCESS,
    data: payload,
  };
};

// FAILED TO RETREIVE USERS
const USER_INDEX_FAILURE = 'USER_INDEX_FAILURE';
const fetchIndexFailure = () => {
  return {
    type: USER_INDEX_FAILURE,
  };
};

// THUNK ACTION CREATOR TO FETCH USERS
function $fetchIndex() {
  return (dispatch, getState) => {
    const { meta } = getState().User;

    dispatch(fetchIndexRequest());

    return fetch(
      `${endpoint}/users?${serializeQuery({
        per_page: meta.pageSize,
        page: meta.page - 1,
      })}`
    )
      .then(result =>
        dispatch(
          fetchIndexSuccess({
            data: result.users,
            meta: {
              page: 1 + result.start / result.limit,
              pageSize: result.limit,
              pageTotal: Math.ceil(result.total / result.limit),
              total: result.total,
            },
          })
        )
      )
      .catch(error => dispatch(fetchIndexFailure(error)));
  };
}

with :

function serializeQuery(query) {
  return Object.keys(query)
    .map(key => `${encodeURIComponent(key)}=${encodeURIComponent(query[key])}`)
    .join('&');
}

Action Type and Action Creators for pagination

// SINGLE ACTION TYPE TO CHANGE META DATA
const USER_INDEX_META = 'USER_INDEX_META';

// ACTIONS CREATORS
function $pageSize(pageSize = INDEX_PAGE_SIZE_DEFAULT) {
  if (pageSize < 1) {
    pageSize = 10;
  }

  if (pageSize > 100) {
    pageSize = 100;
  }

  return {
    type: USER_INDEX_META,
    meta: {
      pageSize,
      page: 1,
    },
  };
}

function $page(page = 1) {
  return (dispatch, getState) => {
    const { meta } = getState()[substate];

    if (page < 1) {
      page = 1;
    }

    if (page > meta.pageTotal) {
      page = meta.pageTotal - 1;
    }

    dispatch({
      type: USER_INDEX_META,
      meta: {
        page,
      },
    });
  };
}

Reducer

function reducer(
  state = {
    data: null,
    meta: {
      page: 1,
      pageSize: INDEX_PAGE_SIZE_DEFAULT,
      pageSizeOptions: INDEX_PAGE_SIZE_OPTIONS,
      pageTotal: 1,
      total: 0,
    },
  },
  action
) {
  switch (action.type) {
    case USER_INDEX_META:
      return {
        ...state,
        meta: {
          ...state.meta,
          ...action.meta,
        },
      };
    case USER_INDEX_SUCCESS:
      return {
        ...state,
        data: action.data,
        meta: {
          ...state.meta,
          ...action.meta,
        },
      };
    default:
      return state;
  }
}

Wiring to the view

We used all defined actions in a react component called UserIndexView connected to the store thanks to react-redux npm module. In this component, we used the component Table from Ant Design which contains the configurable property Pagination. The properties of pagination responsible of changing the pagination state are:

onShowSizeChange : the action creator $pageSize is dispatched once the pageSize is changed.
onChange: the action creator $page is dispatched when the page number is changed.
pageSizeOptions: is an array that specifies the sizeChanger options. In our example we have pageSizeOptions = [5, 10, 20, 30, 50, 100].

import React, { Component } from 'react';
import { connect } from 'react-redux';
import { Table, Avatar, Icon, Input, Button } from 'antd';

import { $pageSize, $page, $fetchIndex } from './state';

// provide shared state and actions as props
const withStore = connect(
  (state) => ({
    data: state.User.data,
    meta: state.User.meta,
  }),
  (dispatch) => ({
    dispatch,
  }),
);

// provides shared state and actions as props
const Connector = (C) => withStore(C);

class UserIndexView extends Component {
  componentWillMount() {
    this.props.dispatch($fetchIndex())));
  }
// PAGINATION OPTIONS
  paginationOptions = {
    showSizeChanger: true,
    showQuickJumper: true,
    onShowSizeChange: (_, pageSize) => {
      this.props.dispatch($pageSize(pageSize));
      this.props.dispatch($fetchIndex())));
    },
    onChange: (page) => {
      this.props.dispatch($page(page));
      this.props.dispatch($fetchIndex())));
    },
    pageSizeOptions: this.props.meta.pageSizeOptions,
    total: this.props.meta.total,
    showTotal: (total, range) => `${range[0]} to ${range[1]} of ${total}`,
  };

  render() {
    const pagination = {
      ...this.paginationOptions,
      total: this.props.meta.total,
      current: this.props.meta.page,
      pageSize: this.props.meta.pageSize,
    };

    return (
      <Table
        style={{ backgroundColor: 'white', flex: 1 }}
        dataSource={this.props.data}
        pagination={pagination}
      >
        <Table.Column
          title="Name"
          key="name"
          render={(record) => (<span>{record.name}</span>)}
        />
        <Table.Column
          title="Email"
          key="email"
          render={(record) => (<span>{record.email}</span>)}
        />
      </Table>
    );
  }
}
export default Connector(UserIndexView);

Second Approach: Client-side pagination

In this part, we are going to mention just the trick that differentiates the Client-side pagination from Server-side pagination. As the API does not supply the filtering parameters to send from the client and loads instead the whole data, we will need to load all the data and update pagination options based on our stored state and dispatch actions using Redux.

In the main component UserIndexView already defined, we definitely have no differences, just as we don’t in all actions creators. There are only two small differences in thunk action creator and reducer which will be mentioned in the two pieces of code:

Thunk action creator

...
return fetch(`${endpoint}/users`)
  .then((result) =>
    dispatch(fetchIndexSuccess({
      data: result.users,
      meta: {
        page: 1,
        pageSize: meta.pageSize,
        pageTotal: Math.ceil(result.total / meta.pageSize),
        total: result.total,
      },
    })))
...

Reducer

...
case USER_INDEX_SUCCESS:
  return {
    ...state,
    data,
    meta: {
      ...state.meta,
      ...action.meta,
      pageTotal: Math.ceil(data.length / state.meta.pageSize),
      total: data.length,
    },
  };
...

Conclusion

The purpose of this blog post is to highlight the importance of using pagination even if the restful API we are using does not provide it, and the important role that Redux plays in managing and organizing the whole mechanism.

Bootstrapping your Redux-based React Native app

Fri, 29 Dec 2017 12:20:00 +0100

Several questions come to mind each time we are starting a new React Native project:

Which logical architecure am I going to use for my app?
Why should I retain this architecture over another?
What are the pros and cons of previous experiences and how can we compose a better architecture for the new application?
How can I secure my development cycle for writing a maintainable UI?

In this blog post, I will attempt to address these questions and expose my approach for crafting a React Native app. We wil be focusing on Redux, since it is often our defacto pattern for structuring state and data mutations.

What is the best way to generate a React Native application?

Let’s start at the roots. This is usually one of the first questions I am faced with. Should I fork a boilerplate? Create folders and files manually or use a dedicated generator command? In most cases, I think you should opt in for one of these vendor-provided React Native commands : react-native init or react-native create-app Let’s compare them and see the differences.

react-native init:

Running this command will create among other things two folders: One for android and an ios. These folders provide you the ability to add modifications related to each of the respective native platforms. In other words, the flexibility to alter Java or Objective-C/Swift code as you would do with a regular Xcode or Android Studio project.

As of the rest, react-native init installs all necessary components to start developing your RN app.

react-native create-app:

Running this command, will generate something entirely different from the react-native init. The created application will have an architecture based on a boilerplate defined by Dan Abramov (creator of Redux and member of the React core team), neither an android nor an iOS folder, but an expo folder. My recommendation:

If you are new to React Native use the react-native create-app as you will not have to deal with configurations.

The downside is that you will loose the ability to add some modifications in the native platform code. And that’s what really embarrasses with the “black-box” abstraction that expo brings to the application structure.

That having been said, you certainly figured that I prefer using the first command – react-native init– because it makes the process of altering/writing native code in React Native, natural and straightforward.

What are we going to use as a library for the UI?

After a deep search, I found two libraries that are useful for the UI development the first one is NativeBase and the second is react-native-elements. Again, let’s compare them and see which one outruns the other, not only in terms of UI and visuals, but also regarding flexibility and ease of integration.

NativeBase: As mentioned in their introduction,

NativeBase is a free and open source UI component library for react-native to build native mobile apps for iOS and Android platforms.

This library is rich in components. You can find what you really need most of the time, and more. Yet what really impressed me was its flexibility of use with react-navigation and many other libraries

Speaking of routing, routing is a major topic in React Native and React apps in general. We usually use react-navigation as our default routing library for its simplicity and active community, but you should know that there are other alternatives.

react-native-elements: A cross platform UI toolkit. This library limits its components to the minimum. It is easy to setup and integrate, and has no strict opinion about how you should implement your design.

The choice of the UI library or approach you will use depends on the dimension and complexity of the app. If you are going to create a simple application that does not require many components, I recommend you go for react-native-elements. On the other hand, if you are going to create a fully-fledged component-rich application that needs to be integrated with some other library like redux-form or react-navigation, I think that NativeBase would be more suited in this case.

One last note, please keep in mind that there are other popular React Native UI libraries such as Shoutem and Nachos, and that you can also design your own library! As a matter of fact, the native React Native components provided by Facebook are more than enough to build your own styled components on top of them.

What architecture should I follow for managing the data and logic of my app?

I think this is the most sensitive point when starting a React Native project. In particular, this the critical question I ask my self: How am I going to design the way data mutates and travels across components?

React is an amazing library when it comes to brining managed state to your view. But the designers of the library have made their intent quite clear since the beginning: React is only th V in MVC (if you are using MVC). It provides no support or conventions for how data (states) should be organized and exchanged (props).

This is when Redux comes on stage. Redux is a way of designing the state of your app and how it changes over-time. It is worth noting that Redux is a React-agnostic project with implementations in other libraries than React. You can read a lot about it and learn it on the Redux website.

Yet, even if you chose to go for a Redux approach, there are different ways to redux things that we will discuss in future posts. For today, I am just going to advise you on how to chose your Redux design (assuming you are going for Redux)

Here’s the way I see this. Ask yourself this question: What is the dimension/complexity of my application?. Based on your answer you should go for one of these ways:

Small application: You can use the simple way of putting in place a redux application as described in the redux documentation (Ex: one file for the entire state, no async callback hustle)
Large application: I recommend separating data flows and concerns as topics, using this approach you will have a clean, re-usable and maintainable architecture. The design by topics, is a pattern that is gaining in popularity not only in the React world, but even outside of JavaScript such as in Rails apps. It allows to avoid confusion between the notion of entities and interests. Google it :)

Last but not least, you should be aware that there are other ways to design your app data logic without Redux. These include Facebook’s Flux (from which Redux was inspired) as well as the old-good Presentational/Container components approach.

Wrapping things up

In this post I shared with you my thoughts about how I draft my ideas up before tackling a React Native app project. I did not cover the details of each aspect, nor did I mention other amazing libraries and tools I am using in our RN stack. But I hope I enlightened you about the questions that should be asked prior to embarking on your development journey.

New EMIKETIC Tunis offices and team

Fri, 17 Nov 2017 19:23:00 +0100

We’ve been working on and dreaming of this for a while. Although EMIKETIC started as a little Ruby on Rails adventure in the small coastal city of Nabeul, Tunisia, we’ve always sought to share our vision that great software can, and sometimes have to, be done outside of major city hubs.

For this reason, EMIKETIC is opening its second office(s) in Tunis!

Nabeul is an amazing city. Sun, Mediterranean sea, good food, cheap living and a decent pool of talented techies. I had the chance to grasp this picture not only through my network and friends, but also at events like the Neapolis Web Conference, or the React Meetup we’ve held at Coworky

Yet has come the time where amazing experiences have to become recipes to share.

It’s all about having fun!

Let’s be honest and straight forward. The real reason why we’ve embarked in this journey is fun :) Or more precisely creating an eco-system for our team to be able to go chill and code in Tunis whenever pleases them. As many of you know, EMIKETIC is pre-dominantly female agency. And girls don’t joke with shopping in Tunis ;)

Besides, there are 3 new members who joined the EMIKETIC adventure on a remote basis in Tunis. As this figure is expected to grow, it became clear that an office – or a platform – would be the next move. Likewise, the Nabeul office as a code-retreat halt for the Tunis team.

For serious fun, location is key. This is why we chose the Jasmine Hall co-working space. A quite haven, with an alternative mood and decoration bringing Tunisian art and heritage to the digital nomad world. Plus we share the same flagship colors :)

For more formal business meetings and non-production work sessions, we also did setup a shared office on Avenue Hedi Karray, two blocks away from Jasmine Hall.

Growing but slowly and wisely

It took us sometime before deciding to move out of our comfort zone. After all, EMIKETIC has always been about executing projects right, with a few things done right. For this reason, every step towards today was taken cautiously. And we’ve placed cultural-fitting above all before inviting the right people to join the- team.

That being said, I am really confident about the future of the agency, should it be in Tunis or elsewhere. For as long as culture and DNA are in the mix, there’s no reason others won’t embrace it.

Agency and software ubiquity

On the technology and process level, we go by the French adage of you don’t swap a winning team (on ne change pas une équipe qui gagne).

Ruby on Rails has proven to be immensely powerful for mitigating project management risks, while bringing the right conventions, tools and standards out of the box. Meteor is a bit of a Rails for an ever mutating JavaScript universe :)

React is becoming more than a library, and even an industry we’re determined to embrace further.

Join the adventure!

Interested in joining the cruise? The boat party is just about to start! Feel free checking new job openings coming on Jobi or via our website.

Wheritics: From agency to product startup life

Mon, 05 Jun 2017 18:35:00 +0100

When EMIKETIC was first started in 2014, all we knew is that we loved Ruby on Rails. We wished to bring its agility and clarity to small and medium businesses. Which came true to a certain extent. Then we were introduced to the magic of modern JavaScript and the real-time capabilities it was offering. Falling in love with Meteor and React was utter fate and an ineluctable pleasant choice :)

Early on, following the almighty principles of the lean mindset, we made the decision to stick to a reduced set of technologies, namely those 2 stacks. Which brought us to focus more on the know-how than the how. What followed could only make us proud. In less than two years, EMIKETIC had become an agency with a proven expertise in delivering real solutions to real world problems in real time. As an agency, this was our long sought-after DNA and will always be.

Genesis

In October 2015, we started working on a prototype for a friend who had a problem in mind to solve. The prototype in question involved the usage of a technology that was new to us: iBeacons, also known as BLE (Bluetooth Low Energy) beacon devices.

This prototype quickly became a structured idea, a platform, then a business opportunity and eventually a startup: Wheritics.

The idea is simple: How can we locate occupants in a building in case of an emergency and for their safety? How can we do the same for valuable assets? How can we scale the solution to a large number of buildings 24/7? It all made sense to us because we were already a team of real-time enthusiasts, fancying architectural challenges yet in love with simple and minimalist design patterns. Carpe Diem!

Nonetheless, if you’re still curious in regards with the solution of the problem mentioned above, visit our website or even better, come hear us pitching! :)

Welcome to startup land!

With Wheritics we learnt so much in such a short amount of time. We were literally thrown in the realm of an unclear proximity IoT eco-system (and we’re being nice here by narrowing this madness down only to the “proximity” category). We learnt that while funding was still baking in the oven, you need to balance your revenue streams wisely. We learnt what the true measure of risk and uncertainty actually meant at our scale.

But we also discovered new significances for the words fun, team work and appetite for innovation. Things went so fast and the project got under the spotlights in different countries. We already secured an influential early-adopter. We even made it to the finalists list for the BloomMasters contest, finalists in Seedstars Tunisia and were selected to exhibit at Vivatechnology. Always while having more and more fun!

The future of EMIKETIC and Wheritics

So today, we’re happy to officially announce that Wheritics and EMIKETIC are one and a same team. While working on 2 different businesses, the culture is and will hopefully always be the same.

At EMIKETIC, we will continue to work with a small group of clients, whose concerns we really understand and whom we perceive more as partners and friends rather than customers :) In fact, most of our clients so far, have been either software companies or innovative startups. It’s all about being tuned on the same page.

As for Wheritics, there are a good number of positions that well be opened gradually this year for those who are curious or wish to join. Among which this one that is already online. Future positions will be as challenging and diverse. From DevOps, to JavaScript and Elixir.

We hope you’ll enjoy this new adventure with us! If you have any questions, consider to join either part of the teams, or simply want to express us you support please drop us a message via our website or social media accounts.

React DnD for complex drag and drop interfaces

Wed, 29 Mar 2017 11:46:00 +0100

React DnD is a performant drag and drop library for React, that allows you to create drag and drop interfaces keeping your components separated.

First let’s take a look at React DnD concepts:

React Dnd implemented the HTML5 drag and drop API and Data is the only source of truth for it. This library supports applying different functionalities to different sets of data.

In order to drag and drop, there are a few functions and properties to be declared:

Item: A plain JavaScript object describing what has been dragged.
Type: A type is a string or Symbole that should be unique throughout the whole application.
Monitors: Allows you to specify your drag and drop behavior.
Connectors: Used to assign roles to the DOM Node such as DragSource, DragPreview and DragTarget.

This post is an initial step towards getting how everything fits together.

The best way to illustrate this is by example. We’re going to drag boxes and drop them into the bin.

Installation

We need to install 2 packages:

npm install react-dnd

npm install react-dnd-htlm5-backend

Setting up our app

We’re going to use the the HTML5 backend in our app, so we should add DragDropContext in the top level component in our app.

import React, { Component } from 'react';

import { DragDropContext } from 'react-dnd';
import HTML5Backend from 'react-dnd-html5-backend';

import './App.css';

export class App extends Component {
  render() {
    return (
      <Grid className="App-container" fluid>
        {
          // write your code here
        }
      </Grid>
    );
  }
}
export default DragDropContext(HTML5Backend)(App);

This example will have two major components:

Box: component can be dragged and dropped.
Bin: component where Boxes will be dropped.

Let’s write a constant for the draggable item’s type.

const Types = {
  BOX: 'box',
};

Step 1: Make component draggable

First, we define the Box component.

import React, { Component, PropTypes } from 'react';

export class Box extends Component {
  render() {
    const { color } = this.props;
    const style = {
      backgroundColor: color,
      height: 10vh;
    };
    return (
      <Col md={3}>
       <div style={style}>
         {color}
       </div>
      </Col>
    );
  }
}

Box.propTypes = {
  color: PropTypes.string.isRequired,
};

Then, we wrap the Box component with DragSource to make it draggable.

import { DragSource } from 'react-dnd';
/**
  code
*/
const boxSource = {
  beginDrag(props) {
    return {
      color: props.color,
    };
  },
};
export class Box extends Component {
  render() {
    /**
      code
    */
    return connectDragSource(
      <Col md={3}>
        <div style={style}>{color}</div>
      </Col>
    );
  }
}
Box.propTypes = {
  color: PropTypes.string.isRequired,
  connectDragSource: PropTypes.func.isRequired,
};
export default DragSource(Types.BOX, boxSource, connect => ({
  connectDragSource: connect.dragSource(),
}))(Box);

These are functionalities that help you handle your component and identify its current state:

beginDrag aims at returning a plain JavaScript object describing the data being dragged.

connectDragSource tells the react-dnd that the DOM Node is a valid dragSource.

Step 2: Make a drop target

Now our component is ready to be dragged. Let’s Move to define the component we can drop Boxes into.

We’re keeping things simple and just using DropTarget to make Bin as a drop target.

import React, { Component, PropTypes } from 'react';
import { DropTarget } from 'react-dnd';

const boxTarget = {
  drop(targetProps, monitor) {
    return {
      box: monitor.getItem().color
    };
  },
};

export class Bin extends Component {
  render() {
    const { isOver, connectDropTarget } = this.props;
    const style = {
      backgroundColor: isOver ? 'grey': 'white';
    };
    return connectDropTarget(
      <Col>
         <div style={style}>
            Drag your box here
         </div>
      </Col>,
    );
  }
}
export default DropTarget(Types.BOX, boxTarget, (connect, monitor) => ({
  connectDropTarget: connect.dropTarget(),
  isOver: monitor.isOver(),
}))(Bin);

drop() is a function Called when a compatible item is dropped on the Bin.

connectDropTarget() marks the react element as the droppable node.

You can ask the monitor about the current drop state by calling monitor methods such us monitor.isOver(), monitor.canDrop(), monitor.getItemType()… The best part about this, is that such information allow you to manipulate the component style as illustrated above. the same options are applicable concerning DragSource and results are guaranteed.

Finally, we import Boxes and Bin components in the top level component in the app.

Conclusion

This post carried out the objective of familiarizing developers with react DnD. It can surely help you build, handle and manipulate complicated drag and drop interfaces with a fairly small amount of effort. It is highly advisable you walk the extra mile and discover what this rich library React DnD has to offer yet.

Create your own download manager using Node.js

Wed, 04 May 2016 12:21:25 +0100

You are about to create a download manager, which queues, starts and repeats over a list of downloadable content.

The example used is a download manager for albums of images.

The Rule

Album downloads are queued. They are not simultaneous, and this save us from server overload.

The Downloader object

Downloader is a singleton class, instantiated by the view component to listen for events.

import EventEmitter from 'events';
class DownloadEmitter extends EventEmitter {}

export default class Downloader {
  constructor() {
    this.downloadPath = 'PATH'

    if(!fs.existsSync(this.downloadPath)) {
      fs.mkdirSync(this.downloadPath)
    }

    this.downloadEmitter = new DownloadEmitter()
  }

  static getInstance() {
    if(!instance) {
      instance = new Downloader()
    }

    return instance
  }
  ...
}

In the constructor, we create the folder for downloads, initialize EventEmitter, etc.

But what is EventEmitter? Why do we emit events? View components are waiting for something to happend. Either it is a user action or background process result. Thanks to EventEmitter, Donwloader will process those variables to our views. Users will be happy to see the UI state changing because they only trust what they see.

The Queue vs The data

The queue will hold albums users are going to download. Once donwloaded, an album is removed from the queue.

Data can hold everything. But for simplicity sake, we represent it this way.

{
  "albums": [
    {
      "id": 1,
      "images": [
        { "url": "http://i.imgur.com/aWaZqVs.jpg" },
        ...
      ]
    },
    ...
  ]
}

let queue = {}

getAlbum(index) {
  return queue[Object.keys(queue)[index]]
}

addToQueue(album, cb) {
  const self = this

  // XXX Save each album in a different location?
  let dir = path.join(self.downloadPath, (album.id).toString())
  album.dir = dir

  // Add properties to image donwload progress on a given album
  album.downloadStarted = false
  album.downloadProgress = 0
  album.downloadedImages = []

  queue[album.id] = album

  self.downloadQueuedAction(album.id)

  cb()
}

shiftQueue() {
  let album = this.getAlbum()
  delete queue[album.id]
}

Callback (cb) is a function parameter to execute when we are done with queueing. Callback can perform for example, UI update. Say, ‘Waiting…’

We will see more about ‘downloadQueuedAction’ later.

Download: the main part

Request is an awesome HTTP client for node. Its use is not limited to query an api, but to download data from the Internet, and much more.

In this section, we query the server for images, write them on disk, and move on.

Let’s start with download behaviour.

downloadRequestWithRetry(options, retry, started, progressed, finished) {
  let self = this
  var filename = (options.id).toString()
  var writeStream = fs.createWriteStream(path.join(options.dir, filename))

  let hasErrors = false
  request(options.file, {timeout: 15000})
  .on('response', function(data) {
    // Only init download started callback first time
    if(retry === 0) {
      started(parseInt(data.headers[ 'content-length' ]))
    }
  })
  .on('error', function(err) {
    // When an error occurs, re initiate download with retry incremented.
    // This supposes we are online.
    hasErrors = true
     if(retry < 5) {
      retry ++
      self.downloadRequestWithRetry(options, retry, started, progressed, finished)
    }
  })
  .on('data', function(chunk) {
    progressed(chunk.length)
  })
  .on('end', function() {
    // We don't call finished callback if an image is not successfully downloaded.
    if(!hasErrors) {
      finished()
    }
  })
  .pipe(writeStream)
}

I know it is a long method. But is it not simple enough? First thing that catch your attention is the name of the method. ‘Retry’. Well, if an image download fails due to bad networking, we re execute the same part of the function.

‘error’ and ‘end’ are both events, both called when request origins errors. ‘end’ event is he result of either successfull/failed download. That’s why we add a boolean to check if the download has been finished successfully. To retrieve the size of the image, we listens for ‘response’ event. Finally, ‘data’ event is triggered as the download progresses.

We need a starting point for our downloads. It looks this way:

downloadNext() {
  let self = this

  // Pick the first album on the queue
  let album = self.getAlbum(0)

  self.downloadEmitter.emit('album-download-started')

  let images = album.images

  // Variables to track download progress, totalSize equals to sum of
  // album images size. Received increments itself with every new chunk progress.
  let totalSize = 0
  let received = 0

  images.forEach(function(image) {
    let options = {
      id: (image.id).toString(),
      url: image.url,
      dir: album.dir
    }

    self.downloadRequestWithRetry(options, 0,
      ((size) => {
        totalSize += size
      }),
      ((data) => {
        received += data
        let progress = Math.floor(received / totalSize * 100)

        self.downloadEmitter.emit('album-download-progress', album.id, progress)
      }),
      (() => {
        album.downloadedImages.push(image.id)

        if(album.downloadedImages.length == images.length) {
          self.downloadEmitter.emit('playlist-download-finish', album.id)
          self.downloadFinishedAction()
        }
      })
    )
  })
}

We carefully notice the emitter part. We emit an events when we start downloading an album, to switch from waiting state to downloading. Then we emit the progress event to print progression percentage.

Starting point ‘downloadNext’ is called when first album is queued, or to process download for pending requests.

Methods ‘downloadQueuedAction’ and ‘downloadFinishedAction’ are there to initiate main download action over the queue object. You will notice that we also used underscore helpers to check if our queue object is empty. So don’t forget to import it.

  donwloadQueuedAction() {
    const self = this
    if(isDownloading) {

    }else {
      self.downloadNext()
      isDownloading = true
    }
  }

  downloadFinishedAction() {
    const self = this
    self.shiftQueue()
    if(_.isEmpty(queue)) {
      isDownloading = false
    } else {
      self.downloadNext()
    }
  }

Conclusion

We talked about components and views a bit. We could have used React or Vue.js, two awesome libraries for constructing views. Maybe we will add the UI part in the future.

Doing that way with downloads, we considerably avoided error responses from the server. So it is much safer to process download of one album, and queue others.

Hands On with the New Meteor 1.3

Sat, 02 Apr 2016 13:09:00 +0100

Meteor 1.3 is here and it’s awesome! Much hype has been going on around it with good reason: 1.3 is a real leap in the Meteor development track with impressive improvements in the way the platform integrates itself in the current JavaScript eco-system.

We first heard about 1.3 during a keynote by Matt Debergalis from MDG (the Meteor Development Group) at their february SF dev workshop. We couldn’t wait to try it and had jumped on right away with testing the 8th beta.

ES2015 Modules

Beside the support for modern ES6 syntax since 1.2, in Meteor 1.3, you can now write your own ES2015 modules without having to setup emulation tools such as RequireJS or CommonJS. Managing modules export, import or considerations of circular dependencies or collisions are now matters handled by the platform natively.

Even better, you can package your own modules similarly to NPM modules for usage inside your app.

The Meteor Chef has written an excellent post on the matter.

Native Support for NPM Modules and Package Management

One of the pains of former versions of Meteor, is that you often needed to rely on third-party Meteor packages such as meteorhacks:npm in order to integrate NPM packages that you sometimes needed just for client functionality. From a syntactical point of view, this approach isn’t really easy and clean to maintain. But for the 1.3 release, handling NPM in your Meteor app is as straightforward as managing any other regular NPM based setup. With your package.json placed at the root of the project, you can simply run things like:

npm install --react

As Matt Debergalis brought it up, enabling developers with the flexibility to chose between Meteor or NPM packages is particularly handy if you’re integrating technologies that are under rapid development, such us React. In our case, this proved to be quite helpful. We use React back-to-back with Meteor quite a lot, and while trying to integrate the official React Velocity wrapper, we realised some of the signatures and deps found in React 0.14.8 and needed for Velocity React, weren’t met in the 0.14.3 based Meteor package. Since both projects are neither maintained by the same team, nor released at the same pace, it’s often wiser to go for the official NPM source.

It is also possible now to test your modules in 1.3 as you would for NPM packages. This is discussed in the next section.

And hey! Follow us on the Facebook channel React Tunisia for more updates about React :)

Testings and BDD

Following the announcement of Xolv.io to discontinue future developments of the Velocity testing engine, MDG has now officially announced support for bundled testing utilities in Meteor thanks to a new meteor command dedicated to tests. This is really exciting news because there will be no need to look for fragmented projects here and there to gear up your workflow with testing blocks.

Using Mocha or the testing driver of your choice, you can test both client and server side with reporting capabilities in the browser:

meteor test --driver-package avital:mocha --port 3100

From now on, Meteor will support:

Unit testings, typically for modules and small pieces of code
Integration tests for cross-modules and cross-components. This makes it simpler to implement BDD practices within a continuous integration context
Acceptance tests, or “end-to-end” test where you can leverage tools such as React Test Utilities to manage UI tests on the client side
Load testing for performance and behaviour under stress loads

More resources can be found at the official Meteor guide for tests.

Build Time Improvements

1.3 features a more efficient build toolchain for building Meteor apps faster, but there are still challenges to face along the road. Improving build time and efficiency is one of the strategical key-points of the MDG roadmap for the future releases.

Mobile

While not being fans of non-native approaches to mobile, it is worth mentioning this latest release brings enhanced support for Phonegap and Crodova drivers for trans-coded Meteor mobile web applications. Along with improved debugging utilities (both client/server side) and faster build times.

Conclusion

At EMIKETIC, we opted for Meteor almost a year ago as the platform of choice for real-time and reasonably scalable web-applications. We’ve been taking a close look at each new update the platform had to offer, and had the chance to suffer several of its limitations along the way. Most of these were due to the lack of support of Meteor to some indispensable tools and libraries found in the JS World.

Luckily, 1.3 came to tackle this.