For my last Meteor React app I’ve designed the most simple role based access control. The basic idea is that users can have multiple roles and every action possible is only allowed by a specified set of roles. For my Meteor React app the following scenarios were considered:
Tightly connected reactivity in a react application has the side effect that it is sometimes necessary to delay the execution of a method. Assume you have a search input field that filters elements while typing, every field input creates a search request. In order to get rid of unnecessary search requests you have to wait until a user has finished typing and then start the search. To make this work without a search button, you have to intercept repeating executions (debounce) of the search method within a specified time frame and delay the execution of the last call.
For my current React app in development I’m using Redux to manage the client state. As this is the first time using Redux I’m not quite sure what to put in the store yet. But I’ve decided to give the multilingual labels and wordings a try. Below you’ll find a simple approach on how I made my app multilingual using the Redux client state to store the translated content. I assume you are familiar with Redux and React.
Apollo server and client support real-time subscriptions with web sockets. Compared to Meteor’s out of the box real-time communication this is a lot more difficult to set up. With this short tutorial I’ll give you an example of how you can get a simple reactive subscriptions into your Apollo/React app. The idea is that you use real-time communication for a specific case only, f.g. sending notifications. We will accomplish this in five steps.
- Install project requirements.
- Setup the server schema.
- Add server resolvers.
- Setup the client subscription.
- Modify a component to receive data from a subscription.
For my last project I had to build a web application to administrate a MongoDB database. Due to using Meteor quite a lot I heard about Graphql and the Apollostack. Graphql, which is a specification done by Facebook engineers, promises to be the better REST API (which I hope it is). I became curious and decided the build the server API with Apollo. First I tried to evade using the Meteor as build system as I don’t want to get too accustomed to this full-stack ecosystem. However, building a live-reload server and client build system in ES6 with Node.js, Babel and Webpack was simply too much work compared to building this simple web app. So in result this was my stack:
Together we’ve built an app to create and share events with friends. It was an awesome experience. Yesterday we launched a private version on heroku. For us this was a great accomplishment. I learned a lot from this project and thought about sharing it with world.
Some technical features and challenges we solved:
- Access control for methods, publications and routing.
- Mobile first ui with material design.
- Fulltext search everywhere.
- File upload to Dropbox with Meteor-Files.
- Images with different thumbnails.
- Keyboard navigation in single views.
- Ready for deployment to heroku.
Thanks to the makers of Meteor, React, Mantra and Mantra-CLI.
hey there, I’ve spent as usual a lot of time with React, Mantra and Meteor. While building a simple app I checked out the new Meteor standard for file handling Meteor-Files. It works great, I really recommend this awesome package. But that’s not what I want to show you. The app I’m working on loads pictures form the dropbox api. Downloading the pictures always takes a while. To make sure the user doesn’t get impatient the app is now displaying a spinner when the image is loading. I would to like to show you how I’ve built this image loader and spinner component.
For Meteor there are not many options left when choosing a user account package. The built-in option is the only use- and successful solution so far. The package is well documented and works like a charm. However, whenever I set up the account system in Meteor I am confronted with these two scenarios:
- How can I extend the user profile object with data from a registration form? (A user should be able to edit the profile data himself later on.)
- And how can I add other attributes to the user collection object? (A user should not be able to change a custom attribute himself later on.)
These are two fundamental obstacles almost every developer faces when setting up the account system. There are a lot of solutions out there on how to do this in Meteor properly, but a lot of them are poorly described and make it difficult the get the right idea of how the account system works. It got even more difficult due to API changes and Meteor itself that changed a lot over years. Now I would like to give a good example for this two questions.
Recently I switched my current project from Meteor 1.2 to 1.3. While doing so I reworked the code for my markdown editor. When created the markdown editor in the first place I learned about the necessity of a solid platform to build web editors. So this time I used draft.js as base. Facebook open sourced draft.js a few months ago. They use it almost everywhere on Facebook page, so it should be well-tested.
The markdown editor you’re going to build has these features:
- Instant html preview rendering
- Support for GitHub flavoured syntax and markdown tables
- Drag and drop file upload.
- Copy and paste file upload.
Optionally: File upload with Meteor and FS Collection.