Index signatures

It is possible to denote obj as any, but that defeats the whole purpose of using typescript. obj = {} implies obj is an Object. Marking it as any makes no sense. To accomplish the desired consistency an interface could be defined as follows, using an index signature

interface LooseObject {
    [key: string]: any
}

var obj: LooseObject = {};

OR to make it compact:

var obj: {[k: string]: any} = {};

LooseObject can accept fields with any string as key and any type as value.

obj.prop = "value";
obj.prop2 = 88;

The real elegance of this solution is that you can include typesafe fields in the interface.

interface MyType {
    typesafeProp1?: number,
    requiredProp1: string,
    [key: string]: any
}

var obj: MyType ;
obj = { requiredProp1: "foo"}; // valid
obj = {} // error. 'requiredProp1' is missing
obj.typesafeProp1 = "bar" // error. typesafeProp1 should be a number

obj.prop = "value";
obj.prop2 = 88;

Record<Keys,Type> utility type

Update (August 2020): @transang brought up the Record<Keys,Type> utility type in comments

Record<Keys,Type> is a Utility type in typescript. It is a much cleaner alternative for key-value pairs where property-names are not known. It's worth noting that Record<Keys,Type> is a named alias to {[k: Keys]: Type} where Keys and Type are generics. IMO, this makes it worth mentioning here

For comparison,

var obj: {[k: string]: any} = {};

becomes

var obj: Record<string,any> = {}

MyType can now be defined by extending Record type

interface MyType extends Record<string,any> {
    typesafeProp1?: number,
    requiredProp1: string,
}

While this answers the Original question, the answer here by @GreeneCreations might give another perspective on how to approach the problem.

I've been able to find a way out using the code snippet below

export const validateObjectId = (key: string = 'id'): ObjectSchema => {
  interface Obj {
    [key: string]: Object;
  }

  const object: Obj = {};

  object[key] = Joi.string()
    .regex(/^(?=[a-f\d]{24}$)(\d+[a-f]|[a-f]+\d)/i)
    .required();
  return Joi.object(object);
};

Replace

[field: string]: {
   property1: string,
   property2: string
}

by

    interface Anything {
      [key: string]: any;
    }

And when you're calling then: do this

let item = { property1: "randomTest", property2: "randomTest1", property3: "randomTest3"}

 this.setState({
    [item].property1: "test value 1"
 })

TypeScript doesn't really track type mutations very well; the default stance of the language is that an expression's type represents the possible values that expression can have, and that it does not change over time. So a variable let x: string = "foo" can never hold a number value, and if you think you might want it to, you should have annotated it like let x: string | number = "foo" instead.

Well, there is the concept of type narrowing, where the compiler will take a variable of type X and temporarily treats it as some subtype Y extends X based on control flow analysis. So let x: string | number = "foo" will cause the compiler to see x as narrowed to string, and you can write x.toUppercase() without error. If you reassign x = 4 the compiler will re-widen to string | number and then re-narrow to number so you can then write x.toFixed(2) without error:

let x: string | number = "foo";
x.toUpperCase(); // okay
x.toFixed // error
x = 5; // okay
x.toFixed(); // okay
x.toUpperCase // error

And when I first looked at your question I had some vague hope that maybe we could refactor your code so that it viewed what you were doing as this sort of scope-based type narrowing. There's even some functionality called assertion functions/methods where you annotate a void-returning class method as returning an assertion predicate of the form asserts this is Y where Y extends this, and the compiler knows that calling that function will narrow the type of the class instance.

But in practice it's very hard to use assertion methods, since they require explicit type annotations in places where you wouldn't think to use them (see microsoft/TypeScript#45385 for a feature request to lift this condition), and there's no easy way to use them to re-widen a narrowed type. And in this specific case I wasn't able to get the compiler to see the operation of calling setEquation() on an Activity as a narrowing (due to vagaries of how the compiler measures variance), so calling it as an assertion method had no effect.

The point is, this sort of thing is hard to do.

So instead of trying to do this as a mutation, we can reframe this as having the operations producing results of new types that you store in new variables if you need to refer to them multiple times. This is like using a fluent interface where you chain methods together. The rule here is that you never re-use a variable if you have performed an operation on it which would mutate its state. (You could guard against that by making everything immutable, so activity.setEquation() would return a brand new Activity instead of mutating the existing one, but I'm not going to worry about that now).

For example:

type EquationParams<K extends string> = {
    variables: K[];
};

class Equation<K extends string> {
    id: string;
    equation?: string;
    variables: K[] = [];

    constructor(params: EquationParams<K>) {
        this.id = "test";
        this.variables = params.variables;
    }

    public addVariable<L extends string>(variables: L[] | L): Equation<K | L> {
        const deDupe = new Set<K | L>(this.variables);

        if (variables instanceof Array) {
            variables.forEach((variable) => deDupe.add(variable));
        } else {
            deDupe.add(variables);
        }
        const that = this as Equation<K | L>;
        that.variables = Array.from(deDupe);
        return that;
    }
}

Here, Equation is now generic in the string literal types of the elements of its variables property. If you have an Equation<K> and call addVariable(v) where v is of type L, the compiler returns an Equation<K | L>, using a union type to represent an array of values of type K together with those of type L. Note that we need at least one type assertion in the implementation (const that = this as Equation<K | L>) to convince the compiler to start adding new L variables that are not in Equation<K>.

For completeness, here's Activity, which also needs to keep track of the variables in its equation:

class Activity<K extends string = never> {
    id: string;
    equation: Equation<K>;
    fixedValues: Partial<Record<K, number>>;

    constructor() {
        this.id = "test";
        this.fixedValues = {};
        this.equation = new Equation({ variables: [] });
    }

    public setEquation<L extends string>(equation: Equation<L>): Activity<L> {
        const that = this as Activity<any> as Activity<L>;
        that.equation = equation;
        return that;
    }

    public addFixedValues(fixedValues: Partial<Record<K, number>>): this {
        this.fixedValues = {
            ...this.fixedValues,
            ...fixedValues
        };

        return this;
    }
}

And now we can demonstrate the fluent interface, only reusing variables if the operation does not produce a value of a different type:

const equation1 = new Equation({ variables: ["a", "b"] })
const activity1 = new Activity().setEquation(equation1);
activity1.addFixedValues({ c: 20 }); // error! 
// ----------------------> ~~~~~
// Object literal may only specify known properties, and 'c' 
// does not exist in type 'Partial<Record<"a" | "b", number>>'
activity1.addFixedValues({ a: 20 });

const equation2 = equation1.addVariable("c"); // use new variable to represent new type
const activity2 = activity1.setEquation(equation2); // use new variable to represent new type
activity2.addFixedValues({ c: 20 }); // okay now

Look good!

Playground link to code