DEV Community: Aryse Gabrielle Pagano

Mongoose DB Seed (node/express)

Aryse Gabrielle Pagano — Mon, 26 Dec 2022 18:47:18 +0000

How do you handle seeding DB during development? When working with mock data during development you constantly find yourself resetting the DB, clearing or manually adding entries to it only to eventually have to clear it again, etc...
If that sounds like you, Here's a mini application that will help you.

Suppose you have an array of objects (your mock data) stored in a file somewhere server-side.

const mockUsers = [
  {
    username: "fakemedic",
    email: "med@med.com",
    password: "$2b$10$h036pK1tWvpYRB3Evbq9j.nk57Zh.OwWtzHXTQhgBbaRhS4LIitsC",
    avatar:
      "https://images.unsplash.com/photo-1463453091185-61582044d556?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxzZWFyY2h8Mnx8cmFuZG9tJTIwcGVyc29ufGVufDB8fDB8fA%3D%3D&w=1000&q=80",
  },
  {
    username: "freesoul",
    email: "free@free.com",
    password: "$2b$10$h036pK1tWvpYRB3Evbq9j.nk57Zh.OwWtzHXTQhgBbaRhS4LIitsC",
    avatar:
      "https://images.unsplash.com/photo-1438761681033-6461ffad8d80?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxzZWFyY2h8Mnx8cGVyc29ufGVufDB8fDB8fA%3D%3D&w=1000&q=80",
  },
  {
    username: "DaBom",
    password: "$2b$10$h036pK1tWvpYRB3Evbq9j.nk57Zh.OwWtzHXTQhgBbaRhS4LIitsC",
    email: "dabom@dabom.com",
    avatar:
      "https://images.unsplash.com/photo-1500648767791-00dcc994a43e?ixlib=rb-4.0.3&ixid=MnwxMjA3fDB8MHxzZWFyY2h8MzR8fHBlcnNvbnxlbnwwfHwwfHw%3D&w=1000&q=80",
  },
  {
    username: "lastcaique",
    email: "lastcaique@lastcaique.com",
    password: "$2b$10$h036pK1tWvpYRB3Evbq9j.nk57Zh.OwWtzHXTQhgBbaRhS4LIitsC",
    avatar:
      "https://st2.depositphotos.com/3143277/8644/i/600/depositphotos_86446164-stock-photo-business-man-in-office.jpg",
  },
];

In order to make the magic happen we will use process.argv

I personally name the file for my seeder/clearer seed.js.

Let's now get to work:

We require the mock data we will use, along with mongoose, dotenv, and the Models.

const { mockUsers } = require("../db/mock_data");
const mongoose = require("mongoose");
require("dotenv").config();
const { User, Post } = require("../models/models");

2- Store a connection:

const connection = async () => {
  mongoose.set("strictQuery", false);
  await mongoose
    .connect(process.env.DB_URI, { useNewUrlParser: true })
    .then(() => console.log("DB READY TO SEED"))
    .catch((err) => console.log(err));
};

3- Now we create our first function, in my case is to seed. We call the connection function, and simply CREATE, exiting the process when done:

const seedDB = async () => {
  await connection();
  await User.create(mockUsers)
    .then(() => console.log("Users seeded"))
    .catch((err) => console.log(err));

  process.exit();
};

4- Nothing new (hopefully) up to this point... so let's create another function that will clear the DB:

const clearDB = async () => {
  await connection();
  await User.deleteMany()
    .then(() => console.log("Users deleted"))
    .catch((err) => console.log(err));

  process.exit();
};

5- Finally, argv will handle calling those functions, feel free to console.log it at this point, and run the file: node seed.js
You will get an array with paths for index 0 and 1. BUT, if you add a 'flag', it will be the index 2:

node seed.js --my_flag

This log will have the flag as process.argv[2], allowing us to write scripts on package.json to seed and clear:

PACKAGE.JSON:

  "scripts": {
    "start": "NODE_ENV=production node server/index.js",
    "dev": "nodemon server/index.js",
    "seedDB": "node server/db/seed.js --seedDB",
    "clearDB": "node server/db/seed.js --clearDB"
  },

Finally: based on the flag we will call the functions we created:

if (process.argv[2] === "--seedDB") {
  seedDB();
} else if (process.argv[2] === "--clearDB") {
  clearDB();
}

And DONE! Use the scripts to seed and clear anytime you need =)

React is just JavaScript

Aryse Gabrielle Pagano — Fri, 11 Nov 2022 19:42:51 +0000

Not sure I would personally agree with that. If you ask my opinion, React is not JUST JavaScript but rather a whole bunch of it that I don't have to write.

I don't know about you, but when I first started learning JavaScript one commonly used exercise (DOM and DOM manipulation) was to create a page entirely with Javascript.

That required Imperative Programming, where you write line by line the steps required for something to happen.

Because this post does not intend to dive deep in the rabbit hole, here's a simple and easily readable example:

const body = document.getElementById("body");
const h1 = document.createElement("h1");
h1.innerText = "This is my h1";
body.append(h1);

What you see up there is just JavaScript.
Now let's try to accomplish the same thing with React, which works in a declarative manner:

const HeadEl = ()=> <h1>This is my h1</h1>;

What you see up there, that looks like HTML is JSX (JavaScript XML) which kinda looks like HTML so we can be happy, and then gets compiled via BABEL to something that would look like this:

/*#__PURE__*/React.createElement("h1", null, "This is my h1");

If we were to be curious and console.log(React.createElement) here's a little something from what we get:

function createElementWithValidation(type, props, children) {
  var validType = isValidElementType(type); // We warn in this case but don't throw. We expect the element creation to
  // succeed and there will likely be errors in render.

  if (!validType) {
    var info = '';

    if (type === undefined || typeof type === 'object' && type !== null && Object.keys(type).length === 0) {
      info += ' You likely forgot to export your component from the file ' + "it's defined in, or you might have mixed up default and named imports.";
    }

    var sourceInfo = getSourceInfoErrorAddendumForProps(props);

    if (sourceInfo) {
      info += sourceInfo;
    } else {
      info += getDeclarationErrorAddendum();
    }

    var typeString;

    if (type === null) {
      typeString = 'null';
    } else if (isArray(type)) {
      typeString = 'array';
    } else if (type !== undefined && type.$$typeof === REACT_ELEMENT_TYPE) {
      typeString = "<" + (getComponentNameFromType(type.type) || 'Unknown') + " />";
      info = ' Did you accidentally export a JSX literal instead of a component?';
    } else {
      typeString = typeof type;
    }

    {
      error('React.createElement: type is invalid -- expected a string (for ' + 'built-in components) or a class/function (for composite ' + 'components) but got: %s.%s', typeString, info);
    }
  }

  var element = createElement.apply(this, arguments); // The result can be nullish if a mock or a custom function is used.
  // TODO: Drop this when these are no longer allowed as the type argument.

  if (element == null) {
    return element;
  } // Skip key warning if the type isn't valid since our key validation logic
  // doesn't expect a non-string/function type and can throw confusing errors.
  // We don't want exception behavior to differ between dev and prod.
  // (Rendering will throw with a helpful message and as soon as the type is
  // fixed, the key warnings will appear.)


  if (validType) {
    for (var i = 2; i < arguments.length; i++) {
      validateChildKeys(arguments[i], type);
    }
  }

  if (type === REACT_FRAGMENT_TYPE) {
    validateFragmentProps(element);
  } else {
    validatePropTypes(element);
  }

  return element;
}

All of that is what? Javascript, I agree. But to reduce this entire process into "It's just JavaScript" shows a little bit of lack understanding the very foundation of React, especially if that's all you have to offer when the question pops in a job interview.
Hopefully I got you curious enough to go do some research and have a better understanding about this whole bunch of JavaScript you don't have to write. =)

Project based tutorial caution

Aryse Gabrielle Pagano — Thu, 10 Nov 2022 14:53:21 +0000

Being self-taught, it didn't take me long in my journey to end up exposed to a project-based tutorial. Regardless of the fact that some are extremely high quality, I almost immediately realized that the tutorial is only as good as your approach to it.
Once I engaged in the community (which took me longer than it should have), I was able to confirm what before was a personal realization. Project based tutorials can HURT just as much as it could potentially help.
Coming from a background of education and emergency medical services, I know very well that digesting information and knowing the "why" rather than the "how" is precisely the difference between being competent vs being capable.
Tired of seeing some good mates with amazing portfolios struggling to code real time has led me to write this post. Enough with the copy and paste. You're wasting what is likely good material by taking the wrong approach.
Here's my humble advice. When watching tutorials (especially project based) try your best to learn the concept, rather than "code-along" as its usually advised.
Coding along doesn't have to mean "copy line by line". As a matter of fact, don't even code the SAME project. Come up with your own project that utilizes the same concepts and as you progress through the tutorial, implement the concepts learned.
That will ensure, that you're not memorizing the project, but rather digesting the information being given, and reenforcing the knowledge by true application.
That is how you increase acquired knowledge and is then able to reproduce the skills learned in any scenario. Example: If watching a tutorial on how to fetch data from a particular API, at the end of the tutorial you should be able to feel relatively comfortable with fetching data from ANY API.
To conclude, therefore, project-based tutorials are simply tools. The final outcome of using a tool comes with your decision on how to use it.
Good luck on your journey