In Part 1 of “From Ember to React” series I introduced a pattern to re-use data fetched in a Top-Level component into his children. Then I started to realize that I could make use of this pattern to bring even more ideas from Ember into React! Here are a couple I used lately:
Sometimes we want to show a “Loading indicator” to let the users know when a request is being processed. As suggested by this post, logic and markup should be placed on a top-level component to be reused by subsequent components.
As before, I remembered a handy Ember feature called Loading / Error Substates already baked into the framework itself. Turns out our previous “High-order Component & Wrapper”-pattern is a perfect place to replicate this pattern, as we don’t need to repeat the loader in every single…
While refactoring a section of our React app at HealthTree I stumbled upon a common use-case where a parent route/component could potentially share (part of) his data context with his children components, something like:
| <Route path> | Component | API call |
| /tasks | <TaskList ...> | GET /api/tasks |
| /tasks/:id | <Task ...> | GET /api/tasks/:id |
As a newcomer, the obvious way to handle this in React (& react-router) is to have data fetching logic in both components’ lifecycle methods:
For some use-cases like this one, data fetched in the first component can be re-used for the second one, thus we have an opportunity to potentially save some bandwidth and improve user experience! …
Our main goal with Sundly is to empower people by owning and being in full control of their personal health records.
One of the items in our public roadmap was to have a way to import medical records from existing apps, such as as Apple Health.
Among other features in our backlog, we asked Twitter for feedback on how to prioritize the development:
We’re please to announce a MVP version of such functionality, check out the following video or the steps ahead:
We recently had a 3-day Design Sprint at Ecaresoft. The challenge was about tackling the prioritization of incoming bug fixes, feature requests, technical support, etc… (psst… want to learn what a Design Sprint is? check this out: https://designsprintkit.withgoogle.com)
Naturally, there are already existing solutions in this particular space, like ZenDesk, Jira, FreshDesk, etc. Without entering into many details, we already use some solutions internally at Ecaresoft. Therefore we didn’t want to simplify the whole design sprint output as simply deciding to use new tools, we could do better.
Fast forward to the last part of the design sprint, it consists on throwing out a prototype of the ideas gathered in the prior days. …
At Nimbo X we use Trello to keep track of our Kanban development pipeline. We needed a way to track the card velocity/cadence of our development team. Unfortunately most existing products weren’t free and offered much more functionality. The ones free were outdated or mediocre at best.
The end result is:
You can visit it at: http://caring-eggs.surge.sh/
And check out the source code:
Lately I’ve been thinking how server code is becoming less and less relevant each day, and how everything you needed to code back in the day is now offered as a cloud service at your disposal, such as:
Authentication/authorization (Auth0, Twilio), asset hosting (AWS S3), database (Firebase, Airtable), AI (google prediction API), payment processing (Stripe)…
Recently at Nimbo X we realised our end users would greatly benefit from having a “Desktop-like experience” when using our app, so we set ourselves to produce a first version of it. In this post we’ll explain our experience from a technical point of view.
Publishing it to the “App Stores” distribution channels is still a work in progress, which deserves a post for itself, where we’ll narrate the bureaucratic experience while submitting the app.
Una de las primeras preguntas que nos hacemos como developers después de aprender lo básico de un framework front-end como Ember es:
Cómo creamos aplicaciones para problemas reales, con un backend y una base de datos como cimientos que nos permitirán escalarla?
Ember Data es una capa de abstracción que nos permitirá conectar nuestra aplicación SPA (client-side) con nuestro backend API de manera transparente, asegurando la mayor compatibilidad y la menor fricción posible.
Sin embargo es común que durante la etapa de prototipeo alguna de las siguientes situaciones se presenten:
This is a pet-project I worked on during the Hack Week (July 13–15th) at eCareSoft. It emerged from a casual chat between Jorge Camargo and I discussing ways to achieve dynamic forms for different medical specialties at Nimbo X, while keeping it simple and easy to maintain.
Nevertheless, with the increase of usage among practicians, along with our recent introduction of Medispan, support tickets related to mismatched search queries have become a cause of pain for the team. We knew our users deserve better.