M not defined ...

[VukIgor]

Version 2.2.0 does not work for normal developers that need to include css into existing sites ,works with node due to possibility of importing M from materialize ,not so for direct css linking .
If this version is not for normal usage you should say so, not let devs to run for errors everywhere when 2.2.0 is linked to website

[Jerit3787]

Hi @VukIgor , could you provide a more detailed errors or a link where we can reproduce the issue? Thanks.

edit: can try using latest version (v2.2.1) and see if the issues still persists.

[VukIgor]

At the moment im using 2.1.1 on few websites. When 2.2.0 is called via link from cdn whole css on site is gone and in console is m is not defined ,materialize modules are called via m.autoinit . however 2.2.0 works on site that is running node js .Did not try 2.2.1, will do tonight . Maybe that 2.2.0 is one of

[uscss-nostromo]

https://materializeweb.com/toasts.html

"Show Toast" button does not work. Console shows "Uncaught ReferenceError: M is not defined"

[Jerit3787]

Hi @VukIgor, sorry I just remembered about this issue. I also encountered it when I was upgrading from v2.0.4 to v2.2.0 in my own projects. I couldn't remember the details but I remembered that before this the toast component was refactored before this causing issues including my own project. The refactored also changed from lower case toast to upper case Toast. The changes I did on my project was:

Old implementation:

M.toast({text: "I am a toast"});

New implementation:

new M.Toast({text: "I am a toast"});

It seems like we need to initialize our own M variables before using it. I am not sure if it by design is like that but since you said that in NodeJS environment works well, this might be a valid bug report. But still requires further investigation.

Hi @uscss-nostromo, thanks for reporting as well the documentation issue. There was an issue with the documentation that hasn't been updated to reflect the previous refactor.

I will tag with bug and documentation for this issue for others to investigate.

[danice]

Now each component type is exported, so you can create them directly as

import {  Toast }  from "@materializecss/materialize"
...

new Toast({....})

The AutoInit method is exported as a function. So you can use it as

import { AutoInit }  from "@materializecss/materialize"

....

AutoInit();

Or call individual components init method:

Datepicker.init({....})

Of course all this should be explained in the documentation before closing the issue.

[VukIgor]

I have solved issues just with changing Materialize version , code on my sites is the same and works nice with version 2.2.1 , 2.2.0 was odd one i think :) thanks for advice @danice and @Jerit3787

[wuda-io]

The website is really not ideal, especially with multiple versions. I think we will have to change the process of the versioning the documentation along with each version of the library.

I am thinking we should split the components and make a markdown readme in each component for documentation, which is then compiled to html and aggregated in a new doc version. Edit: See #614

This would be a big change but would solve a lot of issues. I am struggling when it should be done. But probably we should first do 2.2.2 and then step up to 2.3.0. What do you think?

[VukIgor]

The website is really not ideal, especially with multiple versions. I think we will have to change the process of the versioning the documentation along with each version of the library.

I am thinking we should split the components and make a markdown readme in each component for documentation, which is then compiled to html and aggregated in a new doc version.

This would be a big change but would solve a lot of issues. I am struggling when it should be done. But probably we should first do 2.2.2 and then step up to 2.3.0. What do you think?

Sorry that you replied to my deleted comment , I found that whichever version of materialize I declare from cdn in v2 scope after 2.0.4 toast does not work , in 2.2.1 modals are not working either ,they work if you change modal html code and i'm not going to recode 15+ websites I menage every time new version is pushed out . Since version 2.0.4 materialize have issues in every new edit they push .
After 5 years i'm forced to go back to bootstrap instead of materialize . This turns out as my biggest mistake in 17 years of coding websites and apps ,now have to pay few devs for help recode bunch of custom made websites to boostrap ,did not expect such big issues and made my fronends with materialize.
To my honnest opinion there is no sence of inventing hot water and that is exactly what is happening now with this framework .
What is interesting ,few of my sites are node.js sites ,those sites does not have any issues ,i will repeat ... no issues at all ...
As i mentioned in one post previous ,issue is with importing M from materialize .In node you can import that M but not in regular website that uses cdn link ,you cannot do that.

To whoever menages materialize code and making changes -
The most important point of framework is to be scalable ,materialize is not that ...
Let's be real .You broke fine working framework with drastic change of code by inventing hot water even waterheater is invented long time ago ,sure ,it is ok if someone have one website ,just find and replace code with every new version but .. put your self in my shooes ,is it realy usefull to do that every single time you push new version ? Not to mention how many versions you pushed in last 6 months ...
Sorry for post this long ,just had to say what i think .

[cmorgancli]

Here is a quick and dirty workound I used when supporting multiple versions of materialize....

if (M.toast) { // materialize 2.1.0
    M.toast({toastId: 'alertToast', classes: 'rounded'});
} else {  // materialize 2.1.1+
    new M.Toast({toastId: 'alertToast', classes: 'rounded'});
}