pmn4

// It happens all the time: you have some data, you want to update
// a key without modifying the original object. You typically end
// cloning the original with Object.assign({}, originalObject),
// then adding your new data. This is probably pretty fast, even
// for objects with many keys, but doesn't it seem unnecessary?

function applyNewData(sourceData = { abc: 123, def: 456 }) {
  const newData = { abc: 789 };

  // Previously, we'd write:

pmn4

// Log DB Queries
// *** Warning, this does not capture calls to the Meteor-defined
// /<Collection>/<action> methods, which don't seem to be heavily utilized in
// this project.

import { Mongo } from "meteor/mongo";
// import { MongoInternals } from "meteor/mongo";
import { Logger } from "/server/api";

export const Colors = {

pmn4

.editor
var os = require("os");

function schemaToGraphQl(schema) {
  const definitions = Object.keys(schema._schema).map((name) => {
    const s = schema._schema[name];
    return [
      s.label && `  "${s.label}"`,
      `  ${name}: ${s.type.definitions[0].type.name}` // brittle
    ].filter(s => s).join(os.EOL)

pmn4

module InflateBelongsTo
  # when you have an array of models, but want to include (or even map)
  # an associated resource, this method puts together a single query to
  # fetch the data, then appends it to the model, cutting down on total
  # database calls.
  # this does the exact same work as eager loading when you first query
  # for a set of models, but is especially useful if you the original
  # query is uneditable (not written by you) or you wish to get results
  # conditionally (i.e., you only want _some_ associations loaded)
  #

pmn4

module InflateHasMany
  # what #inflate is to `belongs_to` associations, #inflate_has_many is
  # to `has_many` associations
  # see: https://gist.github.com/pmn4/eb497edad63065304383bdfcf8d60b47
  #
  # returns a flatmap of all resources
  def inflate_has_many(models, foreign_key, key = self.name.underscore.pluralize.to_sym, resources: nil)
    models = Array(models)

    # determine the set of unique, non-nil model ids

pmn4

module MostRecentBy
  def self.included(klass)
    klass.scope :most_recent_by, ->(group_by_col, max_by_col) {
      from(
        <<~SQL
          (
            SELECT #{table_name}.*
            FROM #{table_name} JOIN (
               SELECT #{group_by_col}, MAX(#{max_by_col}) AS #{max_by_col}
               FROM #{table_name}

pmn4

# Insert into table with a unique token column without a loop
# using `LEFT(UUID(), 8)` as the unique string generator for simplicity,
# feel free to use whatever method you'd like, including generating those
# in memory and putting raw strings into your query

INSERT INTO table(column1, column2, token_column)
SELECT "column1_value", "column2_value", token FROM (
  # create a derived table containing five (feel free to increase)
  # potential unique strings
  SELECT LEFT(UUID(), 8) as token

pmn4

class KwargsStruct < Struct
  def initialize(*args, **kwargs)
    # assumes the keyword argument takes priority
    super *members.each_with_index.map { |k, i| kwargs[k] || args[i] }
  end
end

pmn4

/*
  TypeScript can struggle with deserialization. Reading from localStorage,
  dealing with user input, or receiving data from an API are all cases where the
  data coming in may not have the EXACT type we want it to have. Dates are a
  perfect example, in that they are typically serialized as a string, which
  makes deserializing them impossible since we cannot distinguish between a
  string that is intended to be a Date and one that is intended to be the string
  representation of a date.

  Hence, the Deserialized type:

pmn4

/*
  I find that the edges of serialization are the greatest weaknesses for
  TypeScript projects. Further, with API routes, I like to be as declarative
  as possible, so the code (the types) can be documentation for both client
  and server.

  With this type, URL path parameters can be extracted from path string:
*/

// URL param values come in as a string or an array of strings