If you want to tackle the problem in JavaScript using functional programming, the solution is quite straightforward - utilize functions! Instead of overcomplicating things, you can achieve the same outcome with just a few lines of code:

// getValue :: DOMNode -> String
const getValue = field => field.value;

// readForm :: Array DOMNode -> Array String
const readForm = formFields => formFields.map(getValue);

readForm(Array.from(document.querySelectorAll('input, textarea, select')));
// -> ['Value1', 'Value2', ... 'ValueN']

The key consideration lies in how the Field::getValue() function is implemented and what it actually returns. Specifically, does DropdownField::getValue() differ significantly from AutocompleteField::getValue() or NumberField::getValue()? Are they solely responsible for returning values, or do they serve different purposes?

When defining your Field classes and their subtypes, do their distinctions arise from the workings of their getValue() methods or from other functionalities they possess? For instance, the autocomplete feature of a textfield should ideally operate independently of how its value is extracted.

If you do require distinct methods for retrieving values, you can create a function that accepts a map/object containing {fieldtype: readerFunction} pairs:

/* Library code */

// getTextInputValue :: DOMNode -> String
const getTextInputValue = field => field.value;

// getDropdownValue :: DOMNode -> String
const getDropdownValue = field => field.options[field.selectedIndex].value;

// getTextareaValue :: DOMNode -> String
const getTextareaValue = field => field.textContent;

// readFieldsBy :: {String :: (a -> String)} -> DOMNode -> Array String
readFieldsBy = kv => form => Object.keys(kv).reduce((acc, k) => {
  return acc.concat(Array.from(form.querySelectorAll(k)).map(kv[k]));
}, []);



/* Code the library consumer writes */

const readMyForm = readFieldsBy({
  'input[type="text"]': getTextInputValue,
  'select': getDropdownValue,
  'textarea': getTextareaValue
});

readMyForm(document.querySelector('#myform'));
// -> ['Value1', 'Value2', ... 'ValueN']

Please note: I purposely omitted complex concepts like the IO monad to keep things simple, but delving into this area may prove beneficial.

In JavaScript or Object-Oriented Programming language, polymorphism is achieved by incorporating various types.

Absolutely. Alternatively, it can be achieved by implementing the identical type interface in multiple objects.

Is there a way to utilize Javascript polymorphism without OOP classes?

There appears to be some confusion regarding the distinction between classes and types. It is not necessary to use JS class syntax in order to create objects.

You can simply have

const autocompleteField = {
    getValue() {
        …
    }
};
const dropdownField = {
    getValue() {
        …
    }
};

and then utilize both within your Forms instance.

When discussing "polymorphism," the concept can vary depending on context. You may be referring to ad-hoc polymorphism, which is commonly facilitated by type classes in programming languages like Haskell, Scala, or PureScript. In this approach, dispatching is typically achieved by including witness objects as additional function arguments. These witness objects then dictate how to execute the polymorphic behavior.

For instance, consider the following snippet of PureScript code (sourced from the documentation), which defines a show function for various data types:

class Show a where
  show :: a -> String

instance showString :: Show String where
  show s = s

instance showBoolean :: Show Boolean where
  show true = "true"
  show false = "false"

instance showArray :: (Show a) => Show (Array a) where
  show xs = "[" <> joinWith ", " (map show xs) <> "]"

example = show [true, false]

This PureScript code is transpiled into JavaScript, resulting in the following shortened version:

var Show = function (show) {
    this.show = show;
};

var show = function (dict) {
    return dict.show;
};

var showString = new Show(function (s) {
    return s;
});

var showBoolean = new Show(function (v) {
    if (v) {
        return "true";
    };
    if (!v) {
        return "false";
    };
    throw new Error("Failed pattern match at Main line 12, column 1 - line 12, column 37: " + [ v.constructor.name ]);
});

var showArray = function (dictShow) {
    return new Show(function (xs) {
        return "[" + (Data_String.joinWith(", ")(Data_Functor.map(Data_Functor.functorArray)(show(dictShow))(xs)) + "]");
    });
};

var example = show(showArray(showBoolean))([ true, false ]);

This implementation relies on passing additional arguments without any hidden complexities. When dealing with specific concrete types, you must provide the corresponding witness objects accordingly.

In your particular scenario, it would involve circulating a HasValue witness tailored for different structures.

One way to adhere to the open-closed principle is by implementing the factory pattern. According to this principle, software entities should be open for extension but closed for modification.

class FieldValueProviderFactory {
    getFieldValue(field) {
        return this.providers.find(p => p.type === field.type).provider(field);
    }
    registerProvider(type, provider) {
        if(!this.providers) {
            this.providers = [];
        }

        this.providers.push({type:type, provider:provider});
    }
}

var provider = new FieldValueProviderFactory();
provider.registerProvider('DropdownField', (field) => [ 1, 2, 3 ]);
provider.registerProvider('Autocompleter', (field) => [ 3, 2, 1 ]);

class FieldCollection {
    getFieldsValues() {
        this.fields = [ { type:'DropdownField',value:'1' }, { type:'Autocompleter',value:'2' } ];

        let values = [];
        for (let field of this.fields) {
            values.push(provider.getFieldValue(field));
        }
        return values;
    }
}

By registering providers for new field types in the factory, you can add functionality without modifying existing code.

new Field().getFieldsValues();