CSS vs SCSS, currently I have come to the point that the main advantage of SASS for me was splitting the files. Since CSS now provides a solution for variable. Another benefit of SASS is nesting style rules. Which absolutely is a benefit, hence not used carefully could lead to longer selectors with increased specifity.
So currently the ideal situation for me would be able to bundle several css files in to one css file with the right order. One possible option would be to use a cli option like cat on lunix
5. Add the MiniCssExtractPlugin to the plugin section
plugins: [
...
new MiniCssExtractPlugin({
filename: '[name].css',
}),
],
Wrap up
I like this approach, since standard CSS can be used which will improve and extend its responsibilities over time. It will never deprecate which is a huge bonus. And it is flexible, I can make as many bundles as I wish and even decide to leave some CSS files out of the bundling process, for example to make use of HTTP2. A downside might be that you need to remember to manually add the the css files to the `webpack.config.js` file to get the styles.
A second example of a minimal fullstack application to help me to extend my fullstack knowledge. The first application used SQLite. The example in this post does exactly the same thing, the main differences are that MongoDB is used to store the slogans and I extended the React side with Typescript.
Minimal Application
To learn more full stack I first created a minimal React application to connect to a minimal Rest API.
Slogans app React part
This blog post will focus on my experience with MongoDb and Typescript for more explanation about the application check the previous blog post. Start the application with the following steps
Create a local folder for MongoDB sudo mkdir -p /data/db
Set the owner for the folder sudo chown -R $USER /data
The server side code is divided into two node files with the .mjs extension to make use of es6 inside node: server/db.mjs and server/index.mjs
The db.mjs has functions to return the MongoDB connection and to reset and instantiate the collection
The index.mjs is the actual minimal backend for the application, which has all the endpoints for the CRUD actions for the slogans. It keep the MongoDb connection open until the application is closed. As the documentation tells this is the most performing way. All operations of the mongo node client return Promises which makes it use to use. I used a async function for the add endpoint to prevent nesting Promises. I like async functions, hence I do not know yet if they are easier to read and reason about as Promises.
Add endpoint with related async function
app.post("/api/slogan/", (req, res, next) => {
if (!req.body.slogan) {
res.status(400).json({"error": "No slogan specified"});
return;
}
try {
let insertedItem = insertOne(db, 'slogans', req.body.slogan);
return res.json({
"message":"success",
"data": insertedItem
});
} catch (error) {
res.status(400).json({"error": error})
}
});
...
// async functions more to use when multiple async ops are required
const insertOne = async (db, collection, slogan) => {
let collectionCount = await db.collection(collection).find({}).count()
return await db.collection(collection).insertOne({id: (collectionCount + 1), slogan: slogan});
}
Experience with MongoDB
I did have experience with editing mongo db documents with special tooling like Robo3T and NosqlBooster. This was the first time for me to delve deeper into mongo. I must admit that for a JavaScript developer the experience feels more natural as opposed to SQL.
It took a while before I had some knowledge of the basic best practices.Like should I close the connection after each operation, and setting a custom id of should I use the ObjectID provided by Mongo itself. For the latter question I have the feeling that I took the wrong decision and should have used the ObjectID as the main ID. Leason learned 😉 Remember that ObjectID is an object itself when you choose for ObjectID as reference for the documents.
Experience with Typescript
The effect was minimal, since I was reusing an existing application and adding Typescript to it. Nevertheless I can see the benefit hen building a new application while receiving type errors.
I do not think that hints for default type will help me a lot since I do currently not encounter lot of issues with those. But defining type modals, proper DTO’s with types, function parameters eg… that would help alot. I think it could improve coding speed as well since you receive focused information about the code you already have written.
MongoDB for a JavaScript developer feels more natural than SQL, with the latter being able to transfer more logic to the database. And of course having the (dis)advantage of having relations. In a lot of things NoSQL and SQL are absolutely different, but for simple apps both are suitable.
Converting a simple application as this to typescript took less time than expected. For new application I would seriously consider enforce TypeScript. I still do not know if the trade of is worth it. I think it also depends on the type of application; complex fintech app, would not consider to start it without TypeScript. Application displaying items for marketing purposes not so sure is TypeScript would be a requirement…