[New Feature] Initialize Classes by Using an Object Initializer

Hi there, I come from a C# background and it has something great call Object Initializer. Which allows you to initialize an object inline, without specifying the object everytime.
C# docs:
https://msdn.microsoft.com/en-us/library/bb397680.aspx
I would be cool if the compiler could do something like this:
new MyClass { Field1 = "ASD", Field2 = "QWE" };

C# needs this because it doesn't have object literals, but JavaScript doesn't have that problem. MyClass should be defining an appropriate constructor if this initialization pattern is common.
class MyClass {
  constructor(initializers: ...) { ... }
}

var x = new MyClass({field1: 'asd', 'field2: 'fgh' });

Ok I understand that, but I'm not suggesting to do it for the same reason, but it would be cool for fast initialization.
In your example it makes you have a constructor and a mapping inside.
But what I'm suggesting, the compiler would do it for you.

What about for all the people who don't want you to break their object constructors?  What solution do you propose for them?

If they want their object constructor, they should use it, but just imagine how it would be cool if compiller would help you to build the object like in C#. Even groovy support this feature.
It is easier way to initialize object with intellisense supporting where when you type the word you get some hint.(like in C#)

I'll also point out that the production for this would necessitate that the open curly brace be on the same line due to ASI rules.
For instance:
new Foo
{
    bar = 10
}

The above is a new-expression followed by a block body.

@DanielRosenwasser Is correct.  But i would not consider this an ASI issue.  The concern here would be syntactic ambiguity.  What was unambiguously a specific construct in ES6 could now have two meanings if we introduced a production like this.  If we did really want this, we'd likely need something very syntactically unambiguous to avoid these problems.
Also, see https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
This violates our goal of "Avoid[ing] adding expression-level syntax."

Yes, I don't consider there to be an issue with ASI, I consider this to be an easy pitfall for users.

Maybe we need a label for "This is a nice idea to bring to ESDiscuss" :wink:

wooooohoooo!)))

May be it is possible to add special rule to compiler. As I understand correctly, the main problem is that the JS ASI provide a cause for this syntax, but I point on that TS convert to JS and JS syntax is just a part of TS.

I would like to +1 this idea. When I have a simple class with many properties and some methods, etc., I would love to have the initializer syntax.
Some wrote that it's possible using interfaces. But now I use a class with methods in it, so I cannot just switch to interfaces. And I don't want to repeat myself by declaring a completely identical interface with all the members being optional.
Here I've read that the solution is to introduce a specific constructor, but that's also not a nice way, because that would use an "implicit interface" for parameter typing, and at the end I would still repeat myself.
some claims that it's only a syntactic sugar. But allowing for example template string for ES5 is a kind of syntactic sugar too IMO.
Also, constraining the opening brace to be at the same line doesn't sound like a very big deal.

I know this is a closed issue, but it's something I'd very much like to see for my code gen situation where I cannot simply switch to using interfaces or add a new constructor.

What about this?
http://stackoverflow.com/a/33752064/3481582
var anInstance: AClass = <AClass> {
    Property1: "Value",
    Property2: "Value",
    PropertyBoolean: true,
    PropertyNumber: 1
};

I know it is closed, but I ask to reconsider and I'm also +1 for this feature - because there are at least two cases where this is not just syntax sugar as far as I can tell.
Example with Function:
interface Foo {
	bar: any;
	(): void;
}

// how to create a Foo?
var foo: Foo;
foo = () => {}; // cannot convert type ... has non-optional property bar which is not present
foo.bar = "initialized!";

Example with Array:
interface Foo<T> extends Array<T> {
	bar: any;
}

// how to create a Foo?
var foo: Foo<any>;
foo = []; // cannot convert type ... has non-optional property bar which is not present
foo.bar = "initialized!";

Having object initializers like C# has would allow these to be handled in a typesafe manner without having to use an any cast and thus losing the check that all mandatory properties of these instances have been added/assigned a value.

Sorry @dolanmiu, I didn't see your post until just now. The problem with that solution is that the constructor is never called. I'm using TypeScript to generate json as input to Json.NET and my constructor guarantees that important type information is serialized, eg. the $type field.

// how to create a Foo?

No need for any:
var foo: Foo;
foo = (() => {}) as Foo;
foo.bar = "initialized!";

You could do something like this, which ensures you pass all required properties:
function mix<T, U extends {[k: string]: {}}>(func: T, properties: U): T & U {
	Object.keys(properties).forEach(k => (func as any)[k] = properties[k]);
	return func as T & U;
}

var foo: Foo;
foo = mix(() => {}, { bar: 'initialized'});

Thanks Ryen for the suggestion. Whether any or Foo is used in the cast was not my point, but the fact the it does need a cast and after that the type safety is no longer warranted for.
I'll try out the mix approach; reading the code here makes me realize that it should work thanks to duck typing but I'll have to see if it does actually do what I need.

here is my solution: just have a all-optional fields parameter on the constructor:
export class Sample implements ISample {
    sampleId: number;
    type: SampleType = SampleType.None;
    width: number = 1
    height: number = 1;
    depth: number = 1;
    data: ArrayBuffer = null;
    meta: { [id: string]: string; } = {};

    constructor(id: number, fields?: {
        type?: SampleType;
        width?: number;
        height?: number;
        depth?: number;
        data?: ArrayBuffer;
        meta?: { [id: string]: string; };
    }){
        this.sampleId = id;
        if(fields) Object.assign(this, fields);
    }
}

usage:
new Sample(7, {
    meta: { "hello": "world" },
});

I think its a simple and effective work-around.

I like it being more like the c# approach where you do not have to write any additional boilerplate, and for a lot of POJOs where you basically just want to pre populate some fields then add other stuff later via API callbacks etc you have the flexibility to do so.
Like for example if I was to do:
export class Person
{
   public name :string;
   public address: string;
   public age: number;
}

Then I wanted to populate various parts I could do:
// Populate name and age
var person = new Person {  name: "foo", age: 10 };

// Which is basically the same as
var person = new Person();
person.name = "foo";
person.age = 10;

However if you do have a custom constructor you can run that instead or as well as, basically I would just want to remove the common boilerplate where you end up having to have really verbose constructors full of optional params and the need to new up and then allocate the next N lines to myInstance.property = someValue;.
So making the c# style object initializer just act like a shorthand for manually applying the fields individually that alone would save time and yield benefits to developers.

@grofit how dies @MeirionHughes preclude that in any way? You're able to run any kind of pre or post initialization logic you would like. Also, it's worth noting that POJOs are generally synonymous with object literals and that is for a reason.

To do what @MeirionHughes does you need to write:
// OTHER CLASS GOODNESS
    public constructor(
        fields?: {
        // one line per field
        }) {
        if (fields) Object.assign(this, fields);
    }
// OTHER CLASS GOODNESS

Also it will only work in ES5 due to the Object.assign, which is fine for most people but some of us have to also support ES3 in the older browsers.
However that ES5 thing to one side, given the more c# style approach it means I don't need to write any boilerplate constructors, the compiler should know what fields are available within the class being instantiated so I do not need to do any of the above code. Why write code yourself to fulfill a task when the compiler could easily do it for you, meaning less code to maintain and more succinct models.

I have to agree with @grofit. Also there are plenty of other cases of typescript having generally unsupported functionality; es7 async/await is a good example; effectively must be transpiled down to at least es7.
Someone needs to propose new Person { name:"joe" } in es9/10/11 then we can pretend the syntax is valid js and can be used in ts;

I thought about this again and the main issue with it is when you have a lot of nesting going on; I guess the initialisation of the objects would have to be flattened down, or use functions to generate them inline.
ts:
return new [
   new Person() {
        name:"Joe"
   },
   new Person() {
        name:"James"
        info: new Info(){
            authority:"High"
        }
   },
];

js:
let person_1 = new Person();
person_1.name = "Joe";
let person_2 = new Person();
person_2.name = "James";
let info_1 = new Info();
info_1.authority = "High"
person_2.info = info_1;

let array_1 = [person_1, person_2];

return array_1;

not amazingly difficult.

If the type just has properties, it should not be a class. If it needs methods or super calls, use a factory.

@aluanhaddad Please see my post Feb 8th for situations where this is needed for type-safety. Using a factory does just shift the problem into the factory method; how to implement the factory in a type-safe manner?
@MeirionHughes I agree that code generation would be simple, but not the way you suggest it. Your approach could lead to a whole lot of variables and also problems in more complex cases (see below)...
I would rather see code like this generated:
return new [
   (function() {
        var o = new Person();
        o.name="Joe";
        return o;
   })(),
   (function() {
        var o = new Person();
        o.name = "James";
        o.info = (function() {
            var o = new Info();
            o.authority:"High"
            return o;
        })();
        return o;
   })()
];

This approach would be straightforward to generate and because it remains a normal JS expression it would not break the semantics. To illustrate the point, take this example:
doSomething(Math.random() > 0.5
        ? new User() { name: "Peter" }
        : new Group() { members = [new User() { name: "John" }] }
    );

What code would your approach generate for this? It cannot know in advance which branch of the conditional statement will be used. The only way to solve this with a "flattening" approach is to generate explicit code for each conditional branch, which will result in up to 2^(number-of-conditionals) code branches, so that does not seem like a viable solution.

@avonwyss I see. I think a better alternative would be to have the compiler track mutations to the type across assignments. The problem with the Function and Array examples is that there is no way to express them declaratively in JavaScript and I fail to see how initializers would help in these cases.

@aluanhaddad My goal would primarily be to have type-safety when creating augmented functions and arrays, in contrast to objects which are created with the new where this would just be nice syntactic sugar for assigning several properties at once.
The compiler could and should tell me if I'm missing mandatory properties (especially when one starts using the nullability checks), however the necessity for a cast makes this plain impossible.
Syntax-wise, a new, array or function creation could be followed by an object literal which defines the properties and their values to be set on the result of the creation expression. Like so:
class Foo {
  bar: any;
}

const foo: Foo = new Foo() {
    bar: 0;
  };

type FnFoo {
  bar: any;
  (): void;
}

const fnFoo: FnFoo = () => {
    doSomething();
  } {
    bar: 10
  };

type ArrFoo<T> = Array<T> & {
  bar: any;
}

const arrFoo: ArrFoo<any> = [1, 2, 3] {
    bar: 20;
  };

Since the object creation is always also implying a call, wrapping the assignments into a function as shown in my previous comment should qualify as being a way to express that in JavaScript IMHO - if you don't think so you need to explain what you mean exactly
Also, with the introduction of readonly in TS2 (#12), it may be a good solution to allow read-only members to be assigned like this for functions and arrays since this can be seen as being part of the construction expression. As of now, it requires another cast to any to work... like this:
type ArrFoo<T> = Array<T> & {
    readonly bar: any;
}

const arrFoo: ArrFoo<any> = [1, 2, 3] as any;
(arrFoo as any).bar = 20;

@avonwyss actually I think that would be very valuable. I would like to avoid the new keyword if possible, but I think what you are proposing actually makes a lot of sense. Thanks for clarifying.

@RyanCavanaugh Your syntax is really not good, as it forces to have the field initializer within the constructor.
The goal of the C# syntax for field initialization is to have clear disctinction between the constructor and and how the fields are initalized.
The only way to do this currently with Typescript is to use
var user = new User();
user.name = 'nqdq';
user.email = 'dqkdq';
// ...

The C# sytax encapsulates the entire initialization within brackets that delimits this.
I personally think that this would be really a great improvement specially as Typescript does not support method/constructor overloading.

1 for this feature. It can save developers for writing a lot of boilerplate code, prettify code and improve program readability.

Honestly, the more TypeScript I write, the more I find myself wanting its features in other languages like C#. Like just the other day I was thinking "man I can't believe I can't say that this property is required and this one is optional".

What about the following.
No new feature is needed here. You can just initialize in the constructor.
Case 1: Every Property
export class Person {
    public id: number;
    public age: number;

    constructor(initializer?: Person) {
        // return if no initializer is passed in
        if (initializer === undefined) {
            return;
        }
        // apply
        Object.keys(initializer).forEach((key, index) => {
            this[key] = initializer[key];
        });
    }
}

const myPerson = new Person({id: 2, age: 12});

Case 2: Just a subset of Properties
Instead of using Person as the initializer type, just use a interface or other object matching the properties.
export class Person {
    public id: number;
    public age: number;

    constructor(initializer?:{ age: number }) {
        // ... same as before ....
    }
}

const myPerson = new Person({id: 2, age: 12});

Instead of { age: number } you can use a interface or other object too.
Now, lets make it reusable
const initializeObject = <TTarget, TSource>(target: TTarget, source: TSource) => {
    if (source === undefined) {
        return;
    }
    Object.keys(source).forEach((key, index) => {
        target[key] = source[key];
    });
};

export class Person {
    public id: number;
    public age: number;

    constructor(initializer?: Person | { age: number}) {
        initializeObject(this, initializer);
    }
}

@Knaackee You do not seem to understand the difference between a constructor and an initializer.

The goal of the C# syntax for field initialization is to have clear distinction between the constructor and and how the fields are initalized.

In your example the constructor takes the responsibility of initializing all the fields. It means that if you want to build your object in 5 different ways, your ctor will be responsible to use 5 different logic to initialize the object, This is absurd.
Sometimes you want such responsibility to live outside of your constructor logic to not pollute your class code.

@linvi Iam aware of that. I just wanted to show a simple solution to set some properties in one line. I know that this is not the same as in c#.

Initialisers are just syntactic sugar, you can have both a constructor AND initialiser code in C#
It just cleans up the code and makes it look nicer
It would be very nice to have this feature
Why has it taken this long for this feature to come through? Is this feature particularly difficult?

@dolanmiu this is tagged "Out of Scope" -- if you want it to happen, you should raise this with the ECMAScript committee as they control the semantics of class initialization

@RyanCavanaugh I do not understand. Typescript is not only reproducing ECMAScript. It is enhancing it. For example ECMAScript has never created interfaces or static typing.
Therefore why does this feature has to be out of scope?

@RyanCavanaugh it is not supposed to be out of scope
Like I said above, object initialisation is only SYNTACTIC SUGAR
It does not affect the way ECMAScript does object construction at all. It is merely a shorthand notation. Which seems reasonable as a feature of Typescript.
Please read up on how C# does object initialisation

@dolanmiu, when considering new TS features, we follow the TypeScript desing goals. It is not about syntactic sugar or not, it is about goal 6. Align with current and future ECMAScript proposals..
The committee has reserved the syntax after : in declaration, and is guarantee not to step on it, so we have  that are for adding syntactic features in the type declaration domain without conflicting with future versions of ECMAScript. For anything else, however, we do not have this guarantee. the committee could use this syntax in the future to mean something different; this would result in a breaking change for our customers, something we do like to avoid whenever possible.
For such proposals, we ask you present them to TC39 to avoid any potiential conflict with the ECMAScript standard.

Right, I don't see this getting any easier now we have typescript 2.1, with which you can do:
class Person {
    public name: string = "default"
    public address: string = "default"
    public age: number = 0;

    public constructor(init?:Partial<Person>) {
        Object.assign(this, init);
    }
}

let persons = [
    new Person(),
    new Person({}),
    new Person({name:"John"}),
    new Person({address:"Earth"}),
    new Person({age:20, address:"Earth", name:"John"}),
];

http://stackoverflow.com/questions/14142071/typescript-and-field-initializers/37682352#37682352

@MeirionHughes interesting, thanks for sharing.

@MeirionHughes Unfortunately this means you lose some type safety on properties without defaults:
{
    class Person {
        public age: number;

        public constructor(init?:Partial<Person>) {
            Object.assign(this, init);
        }
    }

    let persons = [
        new Person(),
        new Person({age:1}),
        new Person({}), // want this to error!
    ];
}

What we actually want is NamedProps = AllProps - PropsWithoutDefaults. I'm not sure mapped types have that flexibility?

yeah this was raised on my SO answer too; I think the only current sane solution there is to define any class member with defaults as optional. i.e.
class Person {
  public name?: string = "default";
  public age: number;

  public constructor(init: Person) {
    Object.assign(this, init);
  }
}

let people = [
  new Person(), //error
  new Person({}), //error
  new Person({ age: 10 }), //ok
  new Person({ age: 10, name: "John" }), //ok
];

Another con there is name would be typed as string | undefined.
I think this really needs subtraction types, #4183

When compiling this error appears: Cannot find name 'Partial'.
typescript version: 2.1.5

Eh, what about
class Person {
	public name: string
	public age: number
}

var p: Person = { age: 23, name: 'Ronald' }

Type safe, intellisense

@wijnsema Yes, type safe, inellisense, but not a Person instance actually, which is quite a drawback :) So for example your constructor will never run.
And note also, that to make this type-compatibility work, you have to define every member of the class, including methods for example.

Consider this syntax:
class Person {
    constructor({ name });
}

instead of
class Person {
    constructor({ name }) {
        Object.assign(this, { name });
    }
}

Consider this syntax:

class Person {
    constructor({ name });
}

instead of

class Person {
    constructor({ name }) {
        Object.assign(this, { name });
    }
}

That seems reasonable except that type annotations on destructured parameters are already extremely unpleasant to write and it is good for parameters to have type annotations so it doesn't buy you much.
Also by omitting
Object.assign(this, { name });

you are missing out on the opportunity to write
Object.feeze(Object.assign(this, { name }));

@aluanhaddad I do, but I always can go back to normal constructor. The thing is that you won't need type annotations on the destructor as they can be inferred by the class's annotations

I think this is pretty darn close to c# style object initializer.
export class EmailOptions {
    constructor(fields?: { replyTo?: string, fromEmail?: string, fromName?: string, recipients?: ContentVariable[], templateName?: string }) {
        if (fields) {
            this.replyTo = fields.replyTo;
            this.fromEmail = fields.fromEmail;
            this.fromName = fields.fromName;
            this.recipients = fields.recipients;
            this.templateName = fields.templateName;
        }
    }
    replyTo: string;
    fromEmail: string;
    fromName: string;
    recipients: ContentVariable[];
    templateName: string;
}

Usage:
let opts = new EmailOptions({
            fromEmail<EMAIL_ADDRESS>            recipients: [new ContentVariable(this.email, 'to')],
            templateName: 'confirmation-to-user'
        });

@1TheMuffinMan doing it manually is useful if you have some that are required; if they're all optional (like in your case just use the Partial trick:
export class EmailOptions {
    constructor(fields:Partial<EmailOptions>
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail: string;
    fromName: string;
    recipients: ContentVariable[];
    templateName: string;
}

@MeirionHughes Ah, that is better. Thanks.

Also, if you don't want to have to worry about maintaining the type in two places in the last example, you could do this:
export class EmailOptions {
    constructor(fields:Partial<EmailOptions> & {replyTo: EmailOptions['replyTo']}) {
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail: string;
    fromName: string;
    recipients: ContentVariable[];
    templateName: string;
}

neat @kitsonk!

Going through this this discussion, I stumbled upon two points that were not obvious to me. Just wanted to mention them for other people who may find this discussion.

Object.assign(this, fields) works in ES6 / ES2015 only.
If a class constructor does not do any work (as in the example above) you don't need to call constructor at all. Instead you can simply do an object assignment:

class EmailOptions {
  replyTo: string; // Required field
  fromEmail?: string;
  fromName?: string;
  templateName?: string;
}

let opts:EmailOptions = {
  replyTo<EMAIL_ADDRESS>  fromEmail<EMAIL_ADDRESS>  templateName: 'confirmation-to-user'
};

@DKroot For 1. there are plenty of polyfills for older JS versions, so having access to this function is not really a problem.
However, 2. is not equivalent to a constructor call, even if you pretend that the constructor does nothing. If you do a opts instanceof EmailOptions you'll get false returned, whereas using the constructor will set the prototype correctly and then it would return true. This is an important difference.

@avonwyss Good point. instanceof might certainly make a difference.

@kitsonk Why can't you do it like this:
type NotReallyPartial<T> = {
    [P in keyof T]: T[P];
};

export class EmailOptions {
    constructor(fields:NotReallyPartial<EmailOptions>) {
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail?: string;
    fromName?: string;
    recipients?: ContentVariable[];
    templateName?: string;
}

This will keep nagging you for missing required fields.

Immutable JS Record Replacement:
class Person {
    readonly name: string;
    readonly age: number;

    constructor(...initData: Partial<Person>[]) {
        Object.assign(this, initPerson, ...initData)
    }
}

const initPerson: Partial<Person> = {
    name: "",
    age: 0,
}

const v1 = new Person()
const v2 = new Person(v1, { name: "AJ", age: 23 })
const v3 = new Person(v2, { age: 24 })

@FrogTheFrog, could you explain what is the difference in using ObjectFields vs. just the type itself:
export class EmailOptions {
    constructor(fields: EmailOptions) {
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail?: string;
    fromName?: string;
    recipients?: ContentVariable[];
    templateName?: string;
}

@rihei  I don't see there being a difference either. There is scope to pull the object fields and, specifically, remove functions. but you can't do that until type operators/subtraction drops.

@rihei Honestly, I don't know... At that time I must have been searching for something that "worked". Then I found some new way to write it, got overexcited and posted here. Only to find out that it's more of the same.

Ok, thank you both! :) I’m new to all this and wasn’t sure I got it right. As a C# programmer I was surprised not to have an object initialization syntax in TS. However, it seems to be a pretty good option to write this kind of one-line constructor to DTO classes etc.

@rihei bear in mind that classes in TypeScript do not play by any means the same that they they play in C#. Thinking otherwise is a road to pain and sadness.
I recommend that you use objects for DTOs instead.

@aluanhaddad, by objects you mean anonymous objects? In most cases I prefer using strongly typed DTOs to make sure they have correct fields on every call site. But this is off-topic here :) I vote for the actual object initialization syntax, but am ok with the current one-line constructor, too.

I am talking about object literals. Object literals are strongly typed.

In JavaScript anonymous objects is not a term commonly used, usually ported from people familiar with other languages...  Objects don't have names in JavaScript, unlike Functions, which can have names and thereby anonymous functions are a thing.  Some people apply the anonymous objects to object literals (e.g. objects created with curly braces, versus a constructor function/class).  And as @aluanhaddad says those are implicitly strongly typed at creation, and their assignability differs slightly in TypeScript because the objects are considered fresh and so they are checked for excess properties at assignment.  The following two lines produce exactly the same output (and should have the same runtime footprint):
new Object();
{};

On the other hand, these are different:
Object.create({});
{};

In that the first, will have a prototype strictly equal to the object literal that is passed in as the create argument, where as the second will only have a prototype strictly equal to Object.prototype.
I still think people are projecting from other languages here...  There are reasons why the language doesn't account for some of these features, because the language essentially has them, just in slightly different syntaxes and constructs.

@kitsonk well stated. I would say that is the correct way to look at it.
I particularly get concerned when people discuss DTO classes because that implies that they plan to put in place an entire layer for serialization features that are already here in the language.
To talk about another language briefly @rihei mentioned C# and, while it is common to serialize and deserialize objects to specific DTO types in that language, it hasn't been necessary  to do that in C# since ~2008.

Sorry for reviving such an old issue, but for anyone still finding the lack of this feature to be an inconvinience, there's this method:
const obj = { ...new MyClass(), field1 = "ASD", field2 = "QWE" };

Of course it would be nice if the prototype was preserved, but I guess we can't have everything...

Base on TypeScript docs...
`export class User {
id: number;
name: string;
email: string;
constructor(id: number, name: string, email: string) {
this.id = id;
this.name = name;
this.email = email;
}
}
`
let newUser = new User(123, "John", "john@mail.com");

@vivatum Of course, a class can have (multiple) constructors which can be used just like in other OO languages. However, (C#) object initializers are quite powerful syntactic sugar because they enabled the ability to initialize an object using arbitrary, ad-hoc combinations of fields. They are good for 2 reasons:

Handy for classes with many fields and initialization needs.
Cover what (vast) majority of constructors do: taking arguments and assigning them to fields thus eliminating the need in writing many constructors

Can you live without object initializers? Of course. Most OO languages do.
Are they a good idea to support? I think so.

What about this?
http://stackoverflow.com/a/33752064/3481582
var anInstance: AClass = <AClass> {
    Property1: "Value",
    Property2: "Value",
    PropertyBoolean: true,
    PropertyNumber: 1
};

In fact, this is what is working in 2018

@manoharreddyporeddy That's a BIG "no no". Your class will not have correct prototype, methods, instance and etc. since you're casting (not constructing) a normal object to type AClass.

@FrogTheFrog
@https://github.com/FrogTheFrog
I am actually running unit tests.
They need input, i have a json object, the casting works fine.

I actually have nested and a long structure.
What is the best way to do, any example?

I am not sure why this exists in first place, when it works perfectly fine.

@manoharreddyporeddy If you have working unit tests then they are simply not checking anything related to what @FrogTheFrog has written. Since the type system of TypeScript is a compile-time thing you will not get any casting error at runtime as you would in Java or C#. This does not change the fact, however, that the prototype chain is not correctly set up, and that you force the compiler to assume that the object has the correct prototype but this will not be true at runtime. This is JS fundamentals.

Perhaps the way to move forward with this issue is to come at it from the existing constructor field syntax: i.e.
class Foo {
  constructor(public myName) { }
}

gets extended to support nesting of public/private:
class Foo {
  constructor(opts: {public myName} ) { }
}

@MeirionHughes The constructor syntax does not address all cases where an object initializer seems to be the only way to avoid unsafe casts as noted earlier in the discussion. An object initializer syntax without support for augmented functions and arrays would be pointless IMHO.

@FrogTheFrog @avonwyss Others
Thanks, I am not an expert in this but is similar structure is below, and it has no functions (Good point you mentioned) in the Cls1
Everything as a class is good in Typescript.
Example:  Below discussion is on what is the best way to do.
class Cls1 {
public key1: string;
public key2: number;
public key3: string;
// no functions - just the object assignment
}
Option 1: ---- I have a complex structure, this is unit testing, this looks very simple to use, I can copy paste the network response from the browser, when several unit tests with different values, then this will fare much easier ----
let obj1: Cls1 = {
key1: 'val1',
key2: 0,
key3: 'val3'
}
Option 2 ---- default constrcutor, and assignments ----
let obj1: Cls1 = new Cls1();
obj1.key1 = 'val1';
obj1.key2 = 0;
obj1.key3 = 'val3';
Option 3 ---- paramterised constructor is needs to be created, inside it assignments ----
let obj1: Cls1 = new Cls1('val1', 0, 'val3');
Option 4
< Any other option you may have, easy for complex structure, and easy to copy paste from JSON object will be better, similar to Option 1>
What is the best option for unit testing?
What is the best option going prod?
Thank you

@manoharreddyporeddy
I have written an answer above this chain, but the feedback is very mixed, so I re-thought about it.
After using TypeScript for a while, I think doing this is best
interface MyOptions {
    name: string;
    age: number;
}

public class Person {
    constructor(private readonly options: MyOptions)
}

then you can do this:
new Person({
    name: "Tom",
    age: 30
})

Advantage of doing it like this is that you are exposing less variables out. It's less leaky
Doing it the classical way like below is bad because now those variables are exposed and can be changed anywhere else in the app:
const klass = new Person();
klass.name = "Tom";
klass.age = 30;

There's nothing stopping you of modifying klass.name anywhere. You could say "oh, but I want it to be changed!". In which I will say, use a setter rather than expose what should be private.
Not only that, but it is less robust. it means its possible to instantiate a Person without a name or age.
What I am trying to say is, its separating the stuff which really should be in the constructor.

I am not sure, if it has changed in newer typescript versions - mine is 3.1.6 -, but this does not compile (regardless if strict or not compiler options):
class MyClass implements MyInterface {
    a: string;
    b: number;

    constructor(i: MyInterface) {
        Object.assign(this, i);
    }
}

interface MyInterface {
    a: string;
    b: number;
}

Error: [ts] Property 'a' has no initializer and is not definitely assigned in the constructor. [2564]
Ideally, I would like to simply write following to let a new class object initialize from other type (like object initializer):
class MyClass implements MyInterface {

    constructor(i: MyInterface) {
        Object.assign(this, i);
    }
}

interface MyInterface {
    a: string;
    b: number;
}

Current error: Class 'MyClass' incorrectly implements interface 'MyInterface'. Property 'a' is missing in type 'MyClass'. [2420]
Did I miss some workaround mentioned above / are the plans to make Object.assign more type aware?

@ford04 I cannot replicate your issue on the Playground (TS 3.2.1-insiders.20181128), even if enabling the strictPropertyInitialization option.

thanks, didn't know about that strictPropertyInitialization option.
My current workaround is to use the bang operator like this
class MyClass implements MyInterface {
    a!: string;
    b!: number;
    constructor(i: MyInterface) { Object.assign(this, i); }

, as I find these strict compiler checks very helpful.

I don't know if this helps, however I've been doing this for my items, it's not the same but it seems to match what we're tying to do here and it follows the typescript syntax style. (I'm on TS 3.1.1 I think)
let car:Vehicle = {
    Brand: "Tesla",
    // gives compiler error for missing values
    // and for child values that are missing
    //Type: "Electric"
};

Coming from a C# background I find object initializers very useful. For a project I'm working on I reached the following solution.
First, define a generic base class (I called it DTO) that will take care of initialization of the properties it receives as an object in the constructor. This class will never be instantiated directly, so I made it abstract. The constructor receives a single parameter, whose type is derived from the generic class EXCLUDING methods.
type ExcludeMethods<T> =
    Pick<T, { [K in keyof T]: T[K] extends (_: any) => any ? never : K }[keyof T]>;

abstract class DTO<T> {
    public constructor(initializer: ExcludeMethods<T>) {
        Object.assign(this, initializer);
    }
}

Now, we can define our "initializable" classes extending it.
class Person extends DTO<Person> {

    public readonly id: string;
    public readonly value1: number;
    public readonly value2: number;

}

const person = new Person({
    id: "id",
    value1: 10,
    value2: 20
});

Type validation and refactoring field names work like a charm. Not as clean as a C# object initializer, but gets its job done

@arturoarevalo This is brilliant! Structs for TypeScript. I find the class/constructor syntax way to verbose and interfaces suck when you need to type check on them. This seems like a nice workaround. Thanks for posting this.

@arturoarevalo It is possible to have constructor initializer in the parent of a class? For example:
abstract class Person{
    someField: string;
    constructor(initializer: SomeMagicHere){
        Object.assign(this, initializer);
    }
}

class Admin extends Person{
    name: string
}

var john =  new Admin({name: 'John'}); // I need to get only the Admin's fields and not also the Person's fields

To fix this I've added an initializer method under Person:
export type ChildObject<Child, Parent> = Partial<Omit<Child, keyof Parent>>;
abstract class Person{
    fill(data: ChildObject<this, Person>){ ... }
}

var john =  (new Admin).fill({role: 'John'}); // proper intellisense

But I don't like this workaround. And setting it in the constructor: constructor(data: ChildObject<this, Entity>) {} gives:  A 'this' type is available only in a non-static member of a class or interface.
For the best DX I need the initializer to go into the constructor


Fix tourguide renaming

Due to the migration to Fiware organization and the renaming, the documentation was outdated. This fixes the issue as well as some other minor ones.

LGTM


updated ReadMe file.

These are the changes

The main README has been updated with more information.
The README for /greetingsapp is updated.
A ReadMe for /rammeter has been added.

Thank you :+1:


VSR: Fix head after recovery from primary repair

This is a tricky one. A replica that crashes while it was starting a new view, after receiving a DVC quorum, but before persisting the SV, may have a "new" head op. Ignoring it is safe, and the simplest solution.
(An alternative would be to bump up the op_head, but that would confuse all of the DVC generation logic since our DVC would have changed from the durable one, which normally isn't allowed.)
Pre-merge checklist
Performance:

[x] I am very sure this PR could not affect performance.

bors d+

bors r+

bors r+


Handle .git files, for submodules

Fixes #106
Not ready for review yet; I need appveyor to build so I can try it in the real world.

I'm not familiar enough with libgit2sharp to construct a repo with submodules for unit tests, but I can confirm that this works as expected in the wild. The submodule projects pick up the correct version height regardless of how they are built.

It's a little unorthodox, because the method is private and static, but I added some tests for FindGitDir() to show that it behaves as expected. (I could do this just with the file system, not needing to actually create a repo with submodules.)

Thanks for the test. I don't like to test non-public methods directly because it causes tests to be brittle in the face of refactoring of internals and by then I've forgotten what a test was good for. I'll try to whip up a real public-facing test tonight.

Yeah, I agree with you about the tests; I was just trying to do what I can. There's also a school of thought that says if you find yourself wanting to test a private method, it should probably be a public method in a different class .....
Regarding your refactoring in 18c29, are you not worried about File.ReadLines() possibly throwing an exception because it turns out to be some odd binary file, or because of permissions? Maybe I was being overly cautious there.

There's also a school of thought that says if you find yourself wanting to test a private method, it should probably be a public method in a different class .....

Yup, and I follow that, when I want to be in the business of supporting that particular method being called by others rather than being free to delete it when I don't like it any more. In this case, I consider it an implementation detail rather than a feature of a versioning library to be able to find submodule boundaries.

are you not worried about File.ReadLines() possibly throwing an exception because it turns out to be some odd binary file, or because of permissions?

I think failing for a legitimate reason (an unexpected comment as the first line of the .git file, for example) is more likely than finding a binary file called .git. And if such a failure occurred, I'd want an error to show up rather than to swallow it and make it super hard to figure out.
As for permissions issues, if you don't have permission to read that file, git would probably fail too. So I think I'm ok with that until a real scenario is reported as suffering from it.

Okay, thanks, sounds good. I appreciate your looking at this so quickly!

I wouldn't have spent much time on it for a while if you hadn't solved the problem for me. :) Thanks.

libgit2sharp evidently doesn't support creating submodules yet. So I settled for checking in a 10KB binary file that contains a repro git repo.


Update to latest version of Terraform in E2E tests

Chore: Update the E2E tests to use a current version of Terraform (preferably the latest)
More:

CloudPosse's Test Harness still uses the old version, so we'd be installing Terraform ourselves rather than using the built-in one

Is this still valid?  I know we've updated before.


Dismissible widget docs say key is optional

The docs for the Dismissible widget say that the key parameter is only required if the Dismissible is a list item. However, key is annotated with @required, and if that annotation is ignored it fails an assert as well.
Should the docs be updated, or is Dismissible not behaving as intended?

From: https://docs.flutter.io/flutter/widgets/Dismissible-class.html

If the Dismissible is a list item, it must have a key that distinguishes it from the other items and its onDismissed callback must remove the item from the list.

Let's just update the docs to admit the key is required.

Docs have been updated, I think this can be closed:

The [key] argument must not be null because [Dismissible]s are commonly
used in lists and removed from the list when dismissed. […]

https://api.flutter.dev/flutter/widgets/Dismissible/Dismissible.html

Hi @dudeofawesome,
Since the doc has been updated specifying key is required, closing this issue as fixed.


Add support for meta in tests

Describe the feature
Specific instances of generic tests should support meta properties:
models:
  - name: orders
    columns:
      - name: order_id
        tests:
          - not_null:
              where: "date > '2021-01-01'"
              meta:
                team: data
                service: "dbt"
                description: "I expect every order ID to be not null."

Should we try to do this in v0.20.1?

Technically, tests used to support meta as a kwarg, and they no longer do. That's sort of a regression (along the lines of https://github.com/dbt-labs/dbt/issues/3599).
The way that this worked was pretty weird and undocumented! I think the meta properties showed up only in test_metadata.meta, not in the node-level meta property (as they do for every other resource type).

If we wait until v0.21:

#3616 will add support for meta as a config, settable in dbt_project.yml. Not yet in that PR: merging config-meta into property-meta
From there, this could be as simple as adding support for meta as a test modifier

This was resolved by #3616!


Using Hypermapper

Messing around with hypermapper and bayesian optimization.

Looks cool! What is the game plan with this?

Closing this as it has been moved to parafil-evaluation.


Update/beta menu enhancement

What are you changing in this pull request and why?
Please see the associated Asana ticket here.
At the time the navbars for mobile and desktop are generated, this code checks if the version linked in the navbar has the isPrerelease: true flag. If it is true, it will append (Beta) to the end of the menu item indicating a beta release.
To preview, view this link.

Check out the desktop navbar versioning dropdown for 1.5, and assure it has "(Beta) attached to it.
Follow the same steps but for the mobile version of the site using the web inspector.
(Optional) You can pull down the branch and add isPrerelease: true to any versions in the dbt-versions.json file to see the functionality work for other versions for testing purposes.

@breezyfasano This is perfect and exactly what we needed. In the Netlify preview I no longer see the beta banner being presented on those pages. Will that still be present too? We'd like to have that banner and the flag in the dropdown versions menu both be displayed

Nice catch on that issue @matthewshaver! @breezyfasano I think I see what's occurring here. The updateVersion method is called on click on lines 117 and 200, and passes the element into that method.
The updateVersion method lives in website/src/stores/VersionContext.js here. It ultimately gets the text from that element, strips the v from v1.5 for example and setting the versionValue to 1.5.
However, now that we are adding (Beta) for prerelease versions, updateVersion is still only stripping the v from the text, so the versionValue becomes 1.5 (Beta), which doesn't match any versions in the dbt-versions.js file.
So we would have to update the updateVersion method to ensure it also strips the (Beta) when it's setting the versionValue variable.
Let me know if you have any questions and we can sync up!

Aaaah thank you SO much Jason, this is exactly what I was looking for! I was figuring something somewhere was reading the menu label to match data, but just couldn't find it. Much appreciated!! I'll let you know if I need a zoom sync. :)


Validate gradlew scripts

Also validate gradlew and gradlew.bat scripts.
These are not blobs so it is harder to overlook something, but I think these should be checked too.

Count me as a +1. I recently saw an attack where someone opened a PR with a malicious gradlew script. It was obvious enough that a reviewer would have noticed, but they exploited another flaw in the workflow that let it run without review. Had the gradlew script been validated, that would have thwarted the attack.


The configure to change the default table name with migrations does not work

Description
If you create a config migrations.php and change the name in the table field, nothing happens, the standard name remains
How To Reproduce
'table'     => 'test_migrations',
Additional Info

Q
A

Framework Version
2.8.3

PHP version
7.3. 24

Operating system
MacOS Big Sir 11.3.1

I found the reason why it doesn't work

There is an error in the documentation, you should specify the name of the file, not migrations, but migration
Secondly, in order to eliminate the error when you start the migration, you need to comment out the directory key


Add Paul to build permissions list

Add myself to the build permissions list so that I can invoke building PRs on my own

build


Feat: Login form & Page

Figma

Result:

Errors validations:

 As a user, I should be able to Sign In to the system using my email & password


Code splitting not working(based on react router's dynamic routes)

Hi!
I'm trying to implement code splitting based on router's dynamic feature(https://github.com/rackt/react-router/blob/master/docs/guides/advanced/DynamicRouting.md) like that
  path: 'course/:courseId',

  getChildRoutes(location, callback) {
    require.ensure([], function (require) {
      callback(null, [
        require('./routes/Announcements'),
        require('./routes/Assignments'),
        require('./routes/Grades'),
      ])
    })
  },

  getIndexRoute(location, callback) {
    require.ensure([], function (require) {
      callback(null, {
        component: require('./components/Index'),
      })
    })
  },

  getComponents(location, callback) {
    require.ensure([], function (require) {
      callback(null, require('./components/Course'))
    })
  }

It works fine in this commit(just react-router and basic server render).
https://github.com/EcutDavid/example-react-router-server-rendering-lazy-routes/commit/6e070ee4a573fefe730dec2eadbe6dc38d0e5529
But it not works on my application based on this project.

Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components). Check the render method of RoutingContext.
Currently my code like that:
-routes
--index.js
// polyfill webpack require.ensure
if (typeof require.ensure !== 'function') require.ensure = (d, c) => c(require)

export default {
  component: 'div',
  getChildRoutes(location, cb) {
    require.ensure([], (require) => {
      cb(null, [
        require('./ShareGraphRoute'),
        require('./AppRoute'),
        require('./NotFoundRoute'),
      ])
    })
  }
}

-routes
--ShareGraphRoute
// polyfill webpack require.ensure
if (typeof require.ensure !== 'function') require.ensure = (d, c) => c(require)

import {
  SHARE_GRAPH_PATH,
} from 'constants/defaults'

export default {
  path: SHARE_GRAPH_PATH,
  getComponent(location, cb) {
    require.ensure([], (require) => {
      cb(null, require('components/ShareGraph'))
    })
  },
}

Seems need change in server.js or I made some mistakes, any hint?
thanks!!

@EcutDavid have you got polifyll in your first file? What babel are you using? If you are using babel6, you need to specify default to use default export in require like this:
...
require('./routes/Announcements').default,
...

is your source hosted somewhere? I can look and help you :)

@svrcekmichal Thanks!
it's not caused by no use .default.
Sorry, it's company's private project, can not display the whole application code....
But it's build based on this repo.
Here is the dependencies: use babel 5.8
"dependencies": {
    "babel-core": "5.8.x",
    "babel-runtime": "^5.8.34",
    "bluebird": "2.10.2",
    "classnames": "^2.1.2",
    "compression": "^1.6.0",
    "d3": "3.5.6",
    "es6-promise": "3.0.2",
    "express": "^4.13.3",
    "falcor": "^0.1.13",
    "falcor-express": "^0.1.2",
    "falcor-http-datasource": "^0.1.2",
    "falcor-router": "^0.2.9",
    "geoip-lite-country": "^1.1.3",
    "history": "1.17.0",
    "hoist-non-react-statics": "^1.0.3",
    "http-server": "^0.7.5",
    "immutable": "^3.7.4",
    "invariant": "^2.2.0",
    "json-loader": "^0.5.2",
    "leaflet": "^0.7.5",
    "lodash": "^3.10.1",
    "mapbox.js": "^2.2.2",
    "match-media": "^0.2.0",
    "numeral": "^1.5.3",
    "piping": "^0.3.0",
    "pretty-error": "^1.2.0",
    "query-string": "^2.4.2",
    "ramda": "^0.18.0",
    "react": "^0.14.2",
    "react-addons-css-transition-group": "^0.14.3",
    "react-addons-test-utils": "^0.14.3",
    "react-autolink-text": "wiredcraft/react-autolink-text",
    "react-dom": "^0.14.2",
    "react-immutable-proptypes": "^1.2.3",
    "react-infinite": "^0.7.3",
    "react-progress": "0.0.9",
    "react-redux": "^4.0.0",
    "react-router": "^1.0.2",
    "react-slider": "^0.6.0",
    "redis": "2.2.5",
    "redux": "^3.0.4",
    "redux-falcor": "^2.3.3",
    "redux-router": "^1.0.0-beta5",
    "redux-thunk": "^0.1.0",
    "reselect": "^2.0.0",
    "rx": "3.1.1",
    "serialize-javascript": "^1.1.2",
    "serve-favicon": "^2.3.0",
    "serve-static": "^1.10.0",
    "topojson": "^1.6.19",
    "transit-js": "^0.8.837",
    "warning": "^2.1.0",
    "webpack-isomorphic-tools": "^0.9.3"
  },
  "devDependencies": {
    "align-text": "^0.1.3",
    "autoprefixer-loader": "^3.1.0",
    "babel-eslint": "4.1.x",
    "babel-loader": "^5.4.0",
    "babel-plugin-react-transform": "^1.1.1",
    "balanced-match": "^0.2.0",
    "benchpress": "2.0.0-alpha.46",
    "better-npm-run": "0.0.2",
    "concat-map": "0.0.1",
    "concurrently": "^0.1.1",
    "css-loader": "^0.23.0",
    "cssnext-loader": "^1.0.1",
    "eslint": "^1.10.2",
    "eslint-plugin-react": "^3.11.1",
    "extract-text-webpack-plugin": "^0.8.2",
    "file-loader": "^0.8.5",
    "fs-extra": "^0.22.1",
    "gh-pages": "0.3.1",
    "glob": "^5.0.14",
    "jasmine": "^2.3.1",
    "node-bourbon": "^4.2.3",
    "node-sass": "^3.4.2",
    "normalize.css": "3.0.3",
    "phantomjs": "^1.9.18",
    "phantomjs-polyfill": "0.0.1",
    "protractor": "3.0.0",
    "react-hot-loader": "^1.3.0",
    "react-transform-hmr": "^1.0.1",
    "redux-devtools": "^2.1.5",
    "reflect-metadata": "^0.1.0",
    "sass-loader": "^3.1.2",
    "strip-loader": "^0.1.0",
    "style-loader": "0.12.3",
    "traceur": "0.0.91",
    "url-loader": "^0.5.7",
    "webpack": "^1.12.9",
    "webpack-dev-middleware": "^1.4.0",
    "webpack-hot-middleware": "^2.5.0",
    "yargs": "^3.17.1"
  }

The error prompted after change below:
+// polyfill webpack require.ensure
+if (typeof require.ensure !== 'function') require.ensure = (d, c) => c(require)
+
 import {
   SHARE_GRAPH_PATH,
 } from 'constants/defaults'
-import ShareGraph from 'components/ShareGraph'

 export default {
   path: SHARE_GRAPH_PATH,
-  component: ShareGraph
+  getComponent(location, cb) {
+    require.ensure([], (require) => {
+      cb(null, require('components/ShareGraph'))
+    })
+  },
 }

But
-routes
--index.js mentioned before, works fine.

@EcutDavid what is output of this?
console.log(require('components/ShareGraph'))

can you compare it with original import?

Here is the output:
{ __esModule: true,
[1]   ShareGraph:
[1]    { [Function: ShareGraph]
[1]      propTypes:
[1]       { chart: [Function: bound checkType],
[1]         location: [Function: bound checkType],
[1]         selectedIndicator: [Object],
[1]         selectedView: [Function: bound checkType],
[1]         switchUserCountry: [Function: bound checkType],
[1]         title: [Function: bound checkType],
[1]         updateSelectionByQuery: [Function: bound checkType] } },
[1]   default:
[1]    { [Function: Connect]
[1]      displayName: 'Connect(ShareGraph)',
[1]      WrappedComponent: { [Function: ShareGraph] propTypes: [Object] },
[1]      contextTypes: { store: [Object] },
[1]      propTypes: { store: [Object] } } }

after see the output, I change cb(null, require('components/ShareGraph')) to cb(null, require('components/ShareGraph').default)
It works!!!!
Why there is no need to add .default in there???
// polyfill webpack require.ensure
if (typeof require.ensure !== 'function') require.ensure = (d, c) => c(require)

export default {
  component: 'div',
  getChildRoutes(location, cb) {
    require.ensure([], (require) => {
      cb(null, [
        require('./ShareGraphRoute'),
        require('./AppRoute'),
        require('./NotFoundRoute'),
      ])
    })
  }
}

@svrcekmichal
Thank you very much!
Could you give me some reference about when to use the default and when not???
Thanks again!

@EcutDavid well, you need to use .default when you need to use old require with es6 default exported content. So it really depends on type of export you use, I can't tell you why the second require works, but you can always try console.log to see output of require.
Or simply paste here source of ShareGraphRoute and ShareGraph component and console.log of their require, so we can see the difference

ShareGraph
/* global __CLIENT__ */
import React, { Component, PropTypes } from 'react'
import { bindActionCreators } from 'redux'
import { connect } from 'react-redux'
import numeral from 'numeral'
import _ from 'lodash'

import * as RouteActions from 'actions/RouteActions'
import * as UserActions from 'actions/UserActions'
import {
  APP_PATH,
  VIEW_CHART,
  VIEW_MAP,
} from 'constants/defaults'
import * as propTypes from 'constants/propTypes'
import {
  indicatorChartSelector,
  locationsChartSelector,
} from 'selectors/dataSelectors'
import {
  selectedFeaturedIndicatorMetaSelector,
  selectedIndicatorMetaSelector,
  selectedIndicatorTypeSelector,
} from 'selectors/indicatorSelectors'
import MapComponent from './MapComponent'
import Chart from './Chart'
import { wbNormal } from 'constants/textFormat'

export class ShareGraph extends Component {

  static propTypes = {
    chart: propTypes.chart.isRequired,
    location: PropTypes.object.isRequired,
    selectedIndicator: PropTypes.string,
    selectedView: PropTypes.string.isRequired,
    switchUserCountry: PropTypes.func.isRequired,
    title: PropTypes.string.isRequired,
    updateSelectionByQuery: PropTypes.func.isRequired,
  }

  componentWillMount() {
    const { location, updateSelectionByQuery, switchUserCountry } = this.props

    updateSelectionByQuery({}, location.query)

    if (__CLIENT__) {
      const xhr = new XMLHttpRequest()
      xhr.open('GET', '/geo/ip', true)
      xhr.onload = function (e) {
        if (xhr.readyState === 4) {
          if (xhr.status === 200) {
            switchUserCountry(JSON.parse(xhr.response).country)
          } else {
            console.error(JSON.parse(xhr.response).error)
          }
        }
      }

      xhr.onerror = function (e) {
        console.error('onerror', xhr.statusText)
      }

      xhr.send()
    }
    numeral.language('wbNormal', wbNormal)
    numeral.language('wbNormal')
  }

  render() {
    const {
      chart: { data, domain },
      location,
      selectedIndicator,
      selectedView,
      title,
    } = this.props

    const onlyLocations = !selectedIndicator
    const url = APP_PATH + location.search

    return (

{ title }

        { (selectedView === VIEW_CHART || onlyLocations) && (
          <Chart
            data={data}
            domain={domain}
            onSelect={() => {}}
            options={{ hideSpinner: true }}
          />
        )}

        { (!onlyLocations && selectedView === VIEW_MAP) && (
          <MapComponent />
        )}

          Data from World Bank

    )
  }
}

function mapStateToProps (state, props) {
  const { view, router } = state
  const onlyLocationsSelected = props.location.query.indicators === undefined

  const chart = onlyLocationsSelected ?
    locationsChartSelector(state) :
    indicatorChartSelector(state)

  const indicator = onlyLocationsSelected ?
    selectedFeaturedIndicatorMetaSelector(state) :
    selectedIndicatorMetaSelector(state)

  return {
    chart,
    selectedView: view.get('selectedView'),
    location: router.location,
    selectedIndicator: selectedIndicatorTypeSelector(state),
    title: _.get(indicator, 'fullname', ''),
  }
}

function mapDispatchToProps (dispatch) {
  return bindActionCreators({
    updateSelectionByQuery: RouteActions.updateSelectionByQuery,
    switchUserCountry: UserActions.switchUserCountry,
  }, dispatch)
}

export default connect(mapStateToProps, mapDispatchToProps)(ShareGraph)

ShareGraphRoute
// polyfill webpack require.ensure
if (typeof require.ensure !== 'function') require.ensure = (d, c) => c(require)

import {
  SHARE_GRAPH_PATH,
} from 'constants/defaults'

export default {
  path: SHARE_GRAPH_PATH,
  getComponent(location, cb) {
    require.ensure([], (require) => {
      cb(null, require('components/ShareGraph').default)
    }, 'ShareGraph')
  },
}

@EcutDavid and console.log of their requires?

@EcutDavid from what i can tell ShareGraphRoute will be exported as object, with keys
default,path and getComponent which can work, because you have path and getcomponent available. But in first ShareGraph you only export default and ShareGraph, but router don't know how to use this object, it's not react component

Route:
{ path: '/share/widget',
getComponent: [Function: getComponent] }
Component:
{ __esModule: true,
[1]   ShareGraph:
[1]    { [Function: ShareGraph]
[1]      propTypes:
[1]       { chart: [Function: bound checkType],
[1]         location: [Function: bound checkType],
[1]         selectedIndicator: [Object],
[1]         selectedView: [Function: bound checkType],
[1]         switchUserCountry: [Function: bound checkType],
[1]         title: [Function: bound checkType],
[1]         updateSelectionByQuery: [Function: bound checkType] } },
[1]   default:
[1]    { [Function: Connect]
[1]      displayName: 'Connect(ShareGraph)',
[1]      WrappedComponent: { [Function: ShareGraph] propTypes: [Object] },
[1]      contextTypes: { store: [Object] },
[1]      propTypes: { store: [Object] } } }

So there it is, your component exported ShareGraph and default and you have to tell router, which of them to use, the overall export is not react component

Got it, that's make sense.
@svrcekmichal  you help me a lot, thanks!

You are welcome :)

Thanks, this helped me track down a bug that was ruining my day!!


RSA key issue with the submodules

Hi Anka,
Please consider changing the .submodules to
`[submodule "Simulator/3rdParty/cmake-git-version-tracking"]
path = Simulator/3rdParty/cmake-git-version-tracking
url = https://github.com/andrew-hardin/cmake-git-version-tracking.git
[submodule "Simulator/3rdParty/CuMatrix"]
path = Simulator/3rdParty/CuMatrix
url = https://github.com/AnkaChan/CuMatrix.git
[submodule "Simulator/3rdParty/MeshFrame2"]
path = Simulator/3rdParty/MeshFrame2
url = https://github.com/AnkaChan/MeshFrame2.git
[submodule "Simulator/3rdParty/oneTBB"]
path = Simulator/3rdParty/oneTBB
url = https://github.com/oneapi-src/oneTBB.git
`
I ran into RSA key issues with the current one
Thanks

Changed. Thank you for pointing out!

Hi Anka, thanks for the update. However, the problem reappeared  due to[submodule "Simulator/3rdParty/polyscope"] 	path = Simulator/3rdParty/polyscope 	url = git@github.com:AnkaChan/polyscope.git
Cheers

Hi Anka, thanks for the update. However, the problem reappeared due to[submodule "Simulator/3rdParty/polyscope"] path = Simulator/3rdParty/polyscope url = git@github.com:AnkaChan/polyscope.git
Cheers

Hi korzen, thank you again for pointing out; it's fixed now


Preserve custom attributes during optimization

It would be helpful to preserve custom attributes when using gltfpack. Currently, if I pass a glb in with a custom _ID vertex attribute, the resulting file has that attribute stripped. Instead, I'd like to see those attributes preserved, and when simplification is applied the indexes that survive simplification should be copied to the new model.
Attached are two glbs with custom _ID vertex attributes.
Archive.zip

Yeah, I had a similar request related to _BATCHID from glTF files. gltfpack in general can't reasonably support completely custom attributes because it requires knowledge about the attribute meaning to be able to pack/compress/optimize it, however it feels very reasonable to support IDs specifically. I was planning on doing this as part of eventual support for EXT_mesh_features but there's probably no specific reason why it can't be done for ID attributes separately.

Potential patch for copying the ID attributes. https://github.com/zeux/meshoptimizer/commit/55d709280f920a6a3e9711175addddd7532356cc

@zeux I'm not entirely understanding why we can't generically handle vertex attributes - I'm probably missing something.
If a user has a custom vertex attribute of a specific type, I'd expect that whichever vertexes are removed, the corresponding indexes for that attribute would also be removed. Is it more complicated than that?

It's not about copying or removal, it's about whether to preserve the type, how to encode the attribute and which compression filters to use, and how/whether to modify the attribute under various transformations. gltfpack performs a full scene reassembly so it ideally needs to know the semantics behind every component of the scene to perform it correctly and optimally. It's possible to encode every attribute as vec4 of floats with no compression, but that defeats the purpose of using gltfpack and may still misbehave under certain transformations like mesh merging depending on what the attribute means.


Prettify CSS styling

Brainstorm different layouts, and work out how to implement.

Really awesome site for colo(u)r pallets: http://www.colourlovers.com/palettes/search?query=forest


Tracking templateId

Fixes #506
Changes proposed in this PR:

Tracking templateId when a new token has been added
Tests have been updated accordingly

This branches off https://github.com/oceanprotocol/ocean-subgraph/pull/498 in order to use the same tests


Track window dimensions

Description
Track the window size of the respective device
Proposed solution
Get Window.innerHeight and Window.innerWidth and add the dimensions to the Browser Meta Object.
In the OlpHttpTransport the screen dimensions will be translated translated to
browser.screen_width and browser.screen_height as defined in Semantic conventions for browser events

@codecapitano did we get this done last quarter? need to move to Q3?

Still open

Thanks for bumping this @Starefossen.
It's a very low hanging fruit.
I think we'll release it with the next Faro version


Uncaught TypeError: Cannot read property 'current' of null

    $('select.popLang').on('change', function(){
        $('select.popLang').select2("destroy");
        var sel = $('select.popLang'),
            iAr = [];
        sel.children('option').attr('disabled',false);
        if (sel.hasClass('noEng')) {
            sel.find('option[value="39"]').attr('disabled',true);
        }
        $.each(sel, function(){
        var itm = $(this).find('option:selected').val();
        iAr.push(itm);
        });
        $.each(iAr, function(key, val){
            if (isNum(val)) {
                sel.find('option[value="'+val+'"]').attr('disabled', true);
            }
        });
        $('select.popLang').select2();
    });

Running this code the first time returns without error. However, after that it returns the error Uncaught TypeError: Cannot read property 'current' of null starting with r.handle in jQuery. Other than this error appearing, everything works. What could be the problem?

This appears to be more of a usage question than a bug report or common feature request.  As we continue to keep the Select2 issue tracker geared towards these two areas, bug reports and common feature requests, we are redirecting usage questions to other communities such as the mailing list, IRC, or Stack Overflow.

FWIW, I'm running into this exact same issue with v4.0.2 of select2.

@epicserve I can reopen this ticket once we get some more information and can confirm it's a bug. If you want to reply to this ticket (or open a new one) using the bug report template that would give us all of the required information to allow us to track the issue down.

I created an abstraction of the issue (https://fiddle.jshell.net/epicserve/vm4181g4/), but I can't seem to duplicate the bug. But in my project it's essentially doing the same thing, weird. Hmmm ...

Facing same issue with select2
$("select").change(function () {
var dropdownidselctor = "#" + $(this).attr("id");
console.info(dropdownidselctor + " value = " + $(dropdownidselctor).val());
if ($(dropdownidselctor + " option:first").val().length == 0 && $(this).val().length > 0) {
$(dropdownidselctor + " option:first").remove();
$(this).select2();
}
});
but if i run this on console  $("#someid").select2(); then it doesn't return any error

Same issue here. Running on chrome console does throw an error for one select2 but not another. Based on #3116 it sounds like dataConnectors are a big mess so try/catching will have to do.

I didn't get enough time to look into this issue. But this error seems to be not affecting anything for me. So I have added a simple null check to avoid this error. I have attached the patch.
select2-v4.0.2.patch.zip

Thanks @sgrgala your path works like a charm

I'm experiencing the same issue and @sgrgala 's solution fixed it for me as well.  IMO his patch should be added to the project -- I honestly can't see any downside for that, but on the upside it will resolve an issue that many of us experience -- even if it's not easy to reproduce.

I'm also having this problem and @sgrgala's patch also fixes it for us. It would be great for this to be merged select2. Nice work @sgrgala :)

I can reopen this ticket once we get some more information and can confirm it's a bug.
@kevin-brown How many users need to write "I am also experiencing this" before you can confirm it's a bug?

@kevin-brown Here is the information: We are setting this.dataAdapter to null and we try to access it during change event and it's not been initialized by then. I believe it is some kind of race condition and it triggers the change event before the initialization of dataAdapter which leads to an error.
A quick fix is to add a null check and we need more investigation on why dataAdapter is not initialized.
Another fix is that we can initialize the dataAdapter if it's null and then proceed.
Please advise what can be the best possible approach.

I use something like this and that error was gone,  just wrap it using setTimeout
$element.on('change', function (event) {
  // do something

  // and finally
  setTimeout(function () {
    $element.select2({
      data: someArrayData
    })
  })
})

So of course I forgot about this issue, and tried to update to select2 v4.0.3.  I spent an hour trying to figure out the issue, only to find that it was this same issue again.
Unfortunately, @sgrgala 's fix which works for 4.0.2 does not work for 4.0.3, so I ended up reverting to 4.0.2
Funny thing...  I was thinking today that I have an extra hour to kill and didn't know what to do with it.  Oh wait.  No, I didn't.

Guys, I have figured out the workaround and the issue in my case.
I am using select2 in a react wrapper and the problem appears because during onChange callback, the component would be re-rendered and Select2 didn't like that.
The fix for me was to add setTimeout to offset the input manipulation (even though it was properly destroyed and re-initialised).

+1

Replace 'change' subscription with specific 'change.select2' helped in my case

Replace:
$("select").change(function () {
...
});
with:
$("select").on("select2:select select2:unselecting", function () {
...
});
It worked for me.

Thanks @Sofoklis1 it worked perfectly

I can confirm that the solution by @ghprod works perfectly in v4.0.3, even with the setTimeout function having essentially a zero value (this is the default value for "delay" if omitted as the second argument of the function).

Hello, I am facing same issue in select2 4.0.3 (select2.full.js)
i am resolved this issue using below fix.
Replace - Line 4808
 Defaults.prototype.reset = function () {
    function stripDiacritics (text) {
      // Used 'uni range + named function' from http://jsperf.com/diacritics/18
      function match(a) {
        return DIACRITICS[a] || a;
      }
          return text.replace(/[^\u0000-\u007E]/g, match);
    }

With -
Defaults.prototype.reset = function () {
    function stripDiacritics (text) {
      // Used 'uni range + named function' from http://jsperf.com/diacritics/18
      function match(a) {
        return DIACRITICS[a] || a;
      }

     // add if condition for checking null in text if text is null then return empty string
      if (text != null) {
          return text.replace(/[^\u0000-\u007E]/g, match);
      }
      return "";
    }

This patch is working for me in  * Select2 4.0.3

@jackryu Thanks.

@Sofoklis1 thanks! It works!

select2:select select2:unselecting

Works before you delete value, aftre you have new error: "Cannot read property 'query' of null"

select2:select select2:unselecting

Works before you delete value (clear cross clicking), after you have new error: "Cannot read property 'query' of null"

I solved the problem by changing
select2:select select2:unselecting
to
select2:select select2:selecting

I faced same problem, it turns out because i've options with null value in text property, simply filter it.

Replace:
$("select").change(function () {
...
});
with:
$("select").on("select2:select select2:unselecting", function () {
...
});
It worked for me with no errors.

Thank you so much, you solved my issue 4 years later!

I got this issue when I tried to update the data of the select 2 on change of the same select.(it was a multiselect, not sure if that makes any difference.)
I guess the issue lies in that the select is not finished doing something before it starts with updating the data??
the above "solutions" didn't fix it, or caused some other issues.
//I did something like this...
 $("#your-select").on("change", () => {
    $("#your-select").select2({data:[
        {
            id: 0,
            text: 'enhancement'
        },
        {
            id: 1,
            text: 'bug'
        },
        {
            id: 2,
            text: 'duplicate'
        },
        {
            id: 3,
            text: 'invalid'
        },
        {
            id: 4,
            text: 'wontfix'
        }
    ]});
});


Wrong path matching algorithm for paths trailing with /*

So, I'm pretty sure this is a bug and shouldn't be the way it works.
Version
6.0.0-beta.0
Steps to reproduce
No particular steps.
Expected Behavior
matchPath("/test/*", "/test123") == null
Actual Behavior
matchPath("/test/*", "/test123") != null

Ok, it was already submitted. Sorry.


Add coverages

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@c36f94e). Click here to learn what that means.
The diff coverage is 100%.

@@           Coverage Diff           @@
##             master     #6   +/-   ##
=======================================
  Coverage          ?   100%
=======================================
  Files             ?      6
  Lines             ?     11
  Branches          ?      0
=======================================
  Hits              ?     11
  Misses            ?      0
  Partials          ?      0

Impacted Files
Coverage Δ

src/components/search-bar.jsx
100% <100%> (ø)

src/layouts/main.jsx
100% <100%> (ø)

src/app.jsx
100% <100%> (ø)

src/layouts/header.jsx
100% <100%> (ø)

src/layouts/about.jsx
100% <100%> (ø)

src/components/navigator.jsx
100% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c36f94e...36fa79e. Read the comment docs.


[WIP] ItemStack and TradeOffer Generators

This adds some dynamic "recipe" generators that can be used to not only generate ItemStacks and TradeOffers. Namely, this adds TradeOfferGenerators to be used and queried for with Villager Careers.
Granted, there was #662, but I feel that with the various "chance" utils introduced from #734 can be of better use and instead of adding new interfaces to populate an ItemStack.Builder, when a BiConsumer is perfectly acceptable, and not only does it achieve full customizability, but it's base intentions are to make semi-random generation simple. @Deamon5550 mentioned he'd be adding some utility methods to WeightedTable so that some cases where the WeightedTable does not have to be re-created every single invocation of BiConsumer.apply for the various ItemStackBuilderPopulators used.

VariableAmount rolls on weighted and chance tables are now in bleeding. eaa2a0eb02c4e7cad44a401d6098f26025fe0337

IMO this use interfaces.
TradeOffer and ItemStackGenerator should be interfaces and having the current implementations renamed.
Or are planning to serialize this? Or is there any other need to use final classes?

How about the ability to upgrade existing trade offers?

IMO this should use interfaces. TradeOffer and ItemStackGenerator should be interfaces and having the current implementations renamed.

It's absolutely useless, the only thing that is really necessary is representing an ItemStackGenerator and a TradeOfferGenerator. The latter of which could be an interface instead of an API final class, however, the ItemStackGenerator would very well do with being in the API as it's very straight forward. There are no real current implementations of either, except for the more obvious one for TradeOfferGenerators which are the main point of the representation in the API.

Or are planning to serialize this?

Not at all, they're generators, much like the World Gen Populator API, they're configurable but not serializable, based on constructs and BiFunctions that are entirely programmable, but not limited to being generated through configuration by a plugin.

Or is there any other need to use final classes?

Aside from control, the ItemStackGenerator doesn't really need to be declared as a class in the API, but given that it does it's job very well, it's a nice addition.

How about the ability to upgrade existing trade offers?

See VillagerRegistry::populateOffers.

How about the ability to upgrade existing trade offers?

See VillagerRegistry::populateOffers.

That impl and the entire TradeOfferGenerator design is for appendind trade offers not altering existing ones.

altering existing ones.

Notice that TradeOffer is immutable, which kinda makes it difficult to say "Go ahead and change these trade offers with these generators."

@gabizou You are over simplifying the matter.
TradeOffers are immutable, but the list they are stored in isn't.
TradeOffer old = offers.get(x);
TradeOffer.Builder builder = TradeOffer.builder().from(old);
builder.maxUses(old.getMaxUses() + 1);
builder.uses(old.getMaxUses() + 1);
TradeOffer updated = builder.build();
offers.set(x, updated);

That's easy to do with working with the data value from Keys.TRADE_OFFERS. Not something the VillagerRegistry should be doing on it's own.

@gabizou It isn't doing anything on its own. It just passes the list of existing trade offers to the TradeOfferGenerator (trade offer upgrade tasks), which explicitly do that/are told to do that.
Another benefit is that you can add a group of TradeOffers instead of just one.
For example make an armourer skilled in a specific Enchantment and add the next level on upgrade.

Level 1: Unenchanted leather armor
Level 2: Unenchanted iron armor
Level 3: Unenchanted diamond armor
Level 4: Diamond armor with protection 1 // Replace protection with any Enchantment
Level 5: Diamond armor with protection 2
Level 6: Diamond armor with protection 3
Level 7: Diamond armor with protection 4
....

@gabizou It isn't doing anything on its own. It just passes the list of existing trade offers to the TradeOfferGenerator (trade offer upgrade tasks), which explicitly do that/are told to do that.
@gabizou It isn't doing anything on its own. It just passes the list of existing trade offers to the TradeOfferGenerator (trade offer upgrade tasks), which explicitly do that/are told to do that.
Not the same but similar to this: #662: TradeOfferGenerator.
Another benefit is that you can add a group of TradeOffers instead of just one.
For example make an armourer skilled in a specific Enchantment and add the next level on upgrade.
Level 1: Unenchanted leather armor
Level 2: Unenchanted iron armor
Level 3: Unenchanted diamond armor
Level 4: Diamond armor with protection 1 // Replace protection with any Enchantment
Level 5: Diamond armor with protection 2
Level 6: Diamond armor with protection 3
Level 7: Diamond armor with protection 4
....
This is possible with NMS generators.

On it's own, the implementation has a custom interface that does modify a List<TradeOffer> with the use of a Random object. However, specifying that it's a TradeOfferGenerator is not within the contract of that interface. For all I care, it can just mutate the current lists by removing all TradeOffers after level 1.
I've since revised the API PR to include both a TradeOfferGenerator and the ability to have TradeOfferListMutators that are accessible in the VillagerRegistry.


fix(react): campaign heading sizes

#513

Pull Request Test Coverage Report for Build 179626129

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.009%) to 70.886%

Totals

Change from base Build 168803201:
0.009%

Covered Lines:
1388

Relevant Lines:
1757

💛  - Coveralls


Handle VarBinder

Please keep in mind this is a WIP and need some love before being mergeable.
The FunctionMultipleMatch test has been updated to:
foo 0 0 = 0
foo 0 1 = 1
foo 1 0 = 10
foo _ 2 = 2
foo 3 _ = 30
foo _ _ = 50
foo 4 n = n
foo m 5 = m
foo m n = 100

AST and Printer now handle let expressions.
Strategy adopted that requires peer review:
When we translate case alternatives we still handle separately the condition which results into a cond LHS and the result which results into a cond RHS. What we do now is providing the result translator with the binders. If the binders are not VarBinder it should do nothing for now. if the binders are VarBinders it should translate the body to a let expression where the bindings are described by the VarBinder and the body is the result for the case expression.
The problem with this issue is that now produces (let ((#t #t)) body) for non-VarBinders and I don't really know how to make it skip the non-VarBinder case.
An alternative solution could be not to use a let binding and instead to rewrite the variables according to the VarBinder.

I think I got something working even if not ideal yet.
(define foo
  (lambda (v)
    (lambda (v1)
      (cond
        ((and (= v 0) (= v1 0)) (let () 0))
        ((and (= v 0) (= v1 1)) (let () 1))
        ((and (= v 1) (= v1 0)) (let () 10))
        ((and #t (= v1 2)) (let () 2))
        ((and (= v 3) #t) (let () 30))
        ((and (= v 4) #t) (let ((n v1)) n))
        ((and #t (= v1 5)) (let ((m v)) m))
        ((and #t #t) (let ((m v) (n v1)) 100))))))

I think this should also close #16


repo for Telegram messaging

hi @chaeplin , sorry to draw issue for my question , as you well done for twitter do you know any repo for Telegram messaging  or have any plan to develop it by yourself

check this:
http://www.esp8266.com/viewtopic.php?f=24&t=4396
https://github.com/Gianbacchio/ESP8266-TelegramBot

tnx buddy , do you have any gitter room or else

@mkeyno no room for me. listener in https://gitter.im/esp8266/Arduino :)


tour: /list route is deeply hided

Context: https://tour.golang.org/list
Hi. Link to list must be placed to first page or included to footer/header of each page. Otherwise it can't be found anywhere. (url tour.golang.org automaticly forward to welcome/1)

There's a better Table of Contents on the right if you click the hamburger menu, I don't think we need to link that page in every lesson.

May be move "hamburger" to up-left corner?


Check status defaults to ok instead of unknown

A threshold check with a single threshold defined in the UI as:
{level: "CRIT", value: 80, type: "greater"}

creates a check which produces a task:
package main
import "influxdata/influxdb/monitor"
import "influxdata/influxdb/v1"

data = from(bucket: "data")
  |> range(start: -15s)
  |> filter(fn: (r) =>(r._measurement == "cpu"))
  |> filter(fn: (r) =>(r._field == "usage_user"))
  |> filter(fn: (r) =>(r.cpu == "cpu0"))
  |> aggregateWindow(every: 15s, fn: mean, createEmpty: false)

option task = {name: "Name this Check", every: 15s, offset: 0s}

check = {
  _check_id: "04b24ecaa80fd000",
  _check_name: "Name this Check",
  _type: "threshold",
  tags: {},
  }

crit = (r) =>(r.usage_user > 80.0)

messageFn = (r) => ("Check: ${ r._check_name } is: ${ r._level }")

data
|> v1.fieldsAsCols()
|> monitor.check(data: check, messageFn: messageFn, crit: crit)

should produce a status with level crit if value is greater than 80,
and unknown if value is less than 80.
Currently produces status with level ok if value is less than 80

Currently produces status with level ok if value is less than 80

I thought this was expected. Its an easy change to make but would require users to also specify the ok condition in order to get recovery messages.

I would expect status to default to unknown and both unknown and ok to generate a recovery message.

if i set CRIT > 80 and OK < 40, what level do i get for a value of 50?

currently ok

if i set CRIT > 80 and OK < 40, what level do i get for a value of 50?

You would get unknown, @ebb-tide if you get ok in that case then its definitely a bug (but a different bug).
If you set CRIT > 80 but do not set an OK condition what level should you get for a 50?
If we say it should be an unknown then you would not get recoveries when the value drops below 80 and users would have to define both CRIT > 80 and OK <=80 in order to get recoveries.
If we say it should be ok then you would get recoveries when the value drops below 80 without requiring the user to explicitly state an ok condition.
If we say that unknowns trigger recoveries then ok and unknown are the exact same thing and there is no purpose in having both.

Adding a bit more to clarify:
There is a difference between setting and not setting the ok condition. If you do not set the ok condition then the default ok condition is true, meaning that any value that does not match a crit,warn or info condition is ok.
A user cannot set the unknown condition, the unknown level is used  if no other level's condition evaluates to true.
So in the case of

if i set CRIT > 80 and OK < 40, what level do i get for a value of 50?

the unknown level is used since the ok condition evaluates to false as well as the crit condition.

I'm so sorry! I tested this with the ok condition set wrong @nathanielc you are totally right

if i set CRIT > 80 and OK < 40, what level do i get for a value of 50?
is unknown.

This behavior is totally ok with me now that I understand it, sorry for the false alarm!


Bootloop after updating from 2.0.15 to 2.0.21 (Stable)

I am running the factorio-docker since October. Until now it was working well, including updating the underlying container to latest or stable.
I was on 2.0.15 for a while, now I was trying to upgrade to stable-2.0.21 and getting the following error, which results a boot-loop:
  1.084 Factorio initialised
   1.091 Info ServerSynchronizer.cpp:20: nextHeartbeatSequenceNumber(0) initialized Synchronizer nextTickClosureTick(0).
   1.091 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(Ready) to(PreparedToHostGame)
   1.091 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(PreparedToHostGame) to(CreatingGame)
   1.091 Loading map /factorio/saves/_autosave3.zip: 44816393 bytes.
   1.388 Loading level.dat: 147279639 bytes.
   1.393 Info Scenario.cpp:178: Map version 2.0.15-4
   6.306 Blueprint storage "blueprint-storage-2.dat" was not found, trying to load previous version storage "blueprint-storage.dat"
   9.004 Loading script.dat: 31278 bytes.
   10.012 Error ServerMultiplayerManager.cpp:84: MultiplayerManager failed: "Error while running reload_script: filesystem error: copy_file "/opt/factorio/data/base/scenarios/freeplay/freeplay.lua" to "/factorio/temp/currently-playing/freeplay.lua" failed: Operation not permitted [/opt/factorio/data/base/scenarios/freeplay/freeplay.lua] [/factorio/temp/currently-playing/freeplay.lua]"
  10.012 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(CreatingGame) to(InitializationFailed)
  10.012 Info CommandLineMultiplayer.cpp:211: Exit point.
  10.017 Info ServerMultiplayerManager.cpp:146: Quitting multiplayer connection.
  10.017 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(InitializationFailed) to(Closed)
  10.017 Info ServerMultiplayerManager.cpp:166: Deleting active scenario (global = true).
  10.022 Warning WriteFileGuard.cpp:81: Couldn't set /factorio/player-data.tmp.json permissions to 777: Operation not permitted
  10.023 Warning WriteFileGuard.cpp:91: Couldn't chown /factorio/player-data.tmp.json: Operation not permitted
  10.092 Info UDPSocket.cpp:233: Closing socket
  10.095 Goodbye

If I go back to 2.0.15 the server starts up and shows up in the public games.

I also encountered a similar issue with stable-2.0.21.
Looking at the logs, it seems that the system is trying to load Map version 2.0.23-0.
Additionally, in my environment, the same problem occurred with version 20.0.15-stable.
2.0.21
   2.912 Error ServerMultiplayerManager.cpp:84: MultiplayerManager failed: "Map version 2.0.23-0 cannot be loaded because it is higher than the game version (2.0.21-5)."
   2.912 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(CreatingGame) to(InitializationFailed)
   2.912 Info CommandLineMultiplayer.cpp:211: Exit point.
   2.930 Info ServerMultiplayerManager.cpp:146: Quitting multiplayer connection.
   2.930 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(InitializationFailed) to(Closed)
   2.930 Info ServerMultiplayerManager.cpp:166: Deleting active scenario (global = true).
   3.052 Info UDPSocket.cpp:233: Closing socket

2.0.15
   4.234 Error ServerMultiplayerManager.cpp:84: MultiplayerManager failed: "Map version 2.0.23-0 cannot be loaded because it is higher than the game version (2.0.15-4)."
   4.235 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(CreatingGame) to(InitializationFailed)
   4.235 Info CommandLineMultiplayer.cpp:211: Exit point.
   4.246 Info ServerMultiplayerManager.cpp:146: Quitting multiplayer connection.
   4.246 Info ServerMultiplayerManager.cpp:806: updateTick(18446744073709551615) changing state from(InitializationFailed) to(Closed)
   4.246 Info ServerMultiplayerManager.cpp:166: Deleting active scenario (global = true).
   4.378 Info UDPSocket.cpp:233: Closing socket
   4.381 Goodbye

10.022 Warning WriteFileGuard.cpp:81: Couldn't set /factorio/player-data.tmp.json permissions to 777: Operation not permitted
10.023 Warning WriteFileGuard.cpp:91: Couldn't chown /factorio/player-data.tmp.json: Operation not permitted

You are not alone, it seems there are several open issues related to permissions

https://github.com/factoriotools/factorio-docker/issues/555
https://github.com/factoriotools/factorio-docker/issues/549
https://github.com/factoriotools/factorio-docker/issues/496
https://github.com/factoriotools/factorio-docker/issues/501
https://github.com/factoriotools/factorio-docker/issues/492
https://github.com/factoriotools/factorio-docker/issues/420


CMD/CTRL + N should create a new tab

This was added in a previous update on desktop app. It's not possible to hijack this from the web browser.


Outputs not accessible

Describe the Bug with repro steps
I am trying to access the outputs returned by the Oracle connector but the output is not accesible unless I click the "Download (Alt or Option + select)" and then it open us in a browser.
I would like to write an expression like outputs('OracleView')?['ResultSets']?['Table1'] but it returns 'null'
Is there a setting that allows to access large data sets ?
What type of Logic App Is this happening in?
Standard (Portal)
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "OracleView": {
                "inputs": {
                    "body": {
                        "query": "select * from v_ext_sap_carrier_list"
                    },
                    "host": {
                        "connection": {
                            "referenceName": "oracle-2"
                        }
                    },
                    "method": "post",
                    "path": "/datasets/default/query/oracle"
                },
                "runAfter": {},
                "type": "ApiConnection"
            },
            "Select": {
                "inputs": {
                    "from": "@ outputs('OracleView')?['ResultSets']?['Table1']",
                    "select": {
                        "Item": "@{item()?['ITEM_ID']}"
                    }
                },
                "runAfter": {
                    "OracleView": [
                        "SUCCEEDED"
                    ]
                },
                "type": "Select"
            }
        },
        "contentVersion": "<IP_ADDRESS>",
        "outputs": {},
        "triggers": {
            "When_a_HTTP_request_is_received": {
                "kind": "Http",
                "type": "Request"
            }
        }
    },
    "kind": "Stateful"
}

Screenshots or Videos

Browser
Chrome
Additional context
No response
AB#25558093

This unfortunately is a limitation we can't quite get around, when the return data is very large, Downloading it directly is the only option.

I see
What about subsequent actions like ‘Select’ or ‘Compose’?
Can I retrieve certain properties from this large dataset?
There has to be a workaround, this is not a small issue , it has great impacts on the ability to support customers .
I had to creat a Dataflow that uses Power Query manipulation to sort this out
Sent from my iPhone
On 28. Oct 2023, at 19:47, Travis Harris @.***> wrote:

This unfortunately is a limitation we can't quite get around, when the return data is very large, Downloading it directly is the only option.
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/LogicAppsUX/issues/3501#issuecomment-1783882142, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5CAO7OFWMDNCUMD5V2ETCDYBVAJZAVCNFSM6AAAAAA6KMJ6YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBTHA4DEMJUGI.
You are receiving this because you authored the thread.Message ID: @.***>

it depends on the size of the output coming back, if it's small enough for us to retrieve it then we show it in UI, otherwise the customer needs to click to download the raw JSON. There are technical limitations to what we can download/show in the UI for this. I'm not sure I understand how this affects customers negatively though beyond needing to read a raw output JSON vs a neat UI(which would very much not be neat with a large output)

Hi Travis
I’ll rephrase -
When it comes to automation , no one is in a position to click anything .
Whether or not the output is well formatted is of no consequence, but if I can manually access the values by writing expressions such as Outputs(‘’) is all that matters.
Will it read it, even with an exceptionally large outputs ?
Thanks
Sent from my iPhone
On 29. Oct 2023, at 02:15, Travis Harris @.***> wrote:

it depends on the size of the output coming back, if it's small enough for us to retrieve it then we show it in UI, otherwise the customer needs to click to download the raw JSON. There are technical limitations to what we can download/show in the UI for this. I'm not sure I understand how this affects customers negatively though beyond needing to read a raw output JSON vs a neat UI(which would very much not be neat with a large output)
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/LogicAppsUX/issues/3501#issuecomment-1783949554, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5CAO7L6ZRTOWIG7QTLRU5LYBWN2HAVCNFSM6AAAAAA6KMJ6YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBTHE2DSNJVGQ.
You are receiving this because you authored the thread.Message ID: @.***>

We’re talking UX? The customer is automating the UX?

We’re talking about the developer’s experience- can the developer access elements in subsequent actions that are part of a large dataset in order to use the outputs in those actions ?
Sent from my iPhone
On 29. Oct 2023, at 03:33, Travis Harris @.***> wrote:

We’re talking UX? The customer is automating the UX?
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/LogicAppsUX/issues/3501#issuecomment-1783980934, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5CAO7NF7ZXCQGD2ZWPJEGLYBW57LAVCNFSM6AAAAAA6KMJ6YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBTHE4DAOJTGQ.
You are receiving this because you authored the thread.Message ID: @.***>

That doesn't actually answer what I'm asking. I'm asking at more of a technical level. Is the problem that hte output of one action isn't being accessible by the next action? If so that's in the runtime and sounds like a bug that I can foward. Or is the issue that the user has to click the download outputs button for large datasets when looking at run history? That's a UI limitation that there isn't much I can do about but the output is still accessible.

The first part
Certain actions can’t access the output , some do
Sent from my iPhone
On 29. Oct 2023, at 06:46, Travis Harris @.***> wrote:

That doesn't actually answer what I'm asking. I'm asking at more of a technical level. Is the problem that hte output of one action isn't being accessible by the next action? If so that's in the runtime and sounds like a bug that I can foward. Or is the issue that the user has to click the download outputs button for large datasets when looking at run history? That's a UI limitation that there isn't much I can do about but the output is still accessible.
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/LogicAppsUX/issues/3501#issuecomment-1784006084, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A5CAO7PHPT4TLQCA3OGAFZDYBXUUFAVCNFSM6AAAAAA6KMJ6YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGAYDMMBYGQ.
You are receiving this because you authored the thread.Message ID: @.***>

OK, in that case I'm going to move this over to the Runtime Github issues list and ping someone on that team to take a look.


Add CHANGELOG for v0.24.0

Closing this PR since the deprecation of azure_ad * tables will be performed in a future release


fixes #709

Codecov Report

Merging #711 into 1.6.x will decrease coverage by 0.10%.
The diff coverage is 72.72%.

@@             Coverage Diff              @@
##              1.6.x     #711      +/-   ##
============================================
- Coverage     49.74%   49.63%   -0.11%
+ Complexity     1915     1914       -1
============================================
  Files           261      261
  Lines         11737    11738       +1
  Branches       1662     1663       +1
============================================
- Hits           5838     5826      -12
- Misses         5209     5222      +13
  Partials        690      690

Impacted Files
Coverage Δ
Complexity Δ

.../main/java/com/networknt/security/JwtVerifier.java
43.04% <72.72%> (-0.29%)
9.00 <0.00> (ø)

...ver/src/main/java/com/networknt/server/Server.java
30.45% <0.00%> (-4.94%)
16.00% <0.00%> (-1.00%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 54fdd72...e7080b3. Read the comment docs.

OK, I will change the file name.
what about: openapi-security-no-default-jwtcertificate.yml

That would be good as long as it is not called security.yml and openapi-security.yml


submodules

We need to put the .NET git submodules here. What do people think about that?

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275