How do I predefine a toast element

Questions
1

In the toast documentation (parameters) under el it says “Toast element. Can be useful if you already have Toast element in your HTML and want to create new instance using this element”

So how do I predefine a toast element? What does that HTML look like? There are no examples in the docs.

Thanks.

2

I just created a toast element via the .create() function and copied that code from the dom and pasted it into my index.html. It looks like this:

        <div class="toast toast-center">
          <div class="toast-content">
            <div class="toast-text">
               <span class="message"></span>
            </div>
          </div>
        </div>

Unless there’s an easier way or something I should know, I’m gonna go with this.

3

wouldn’t such a thing work for you? why do you need an HTML element?

function defaultToast(){

    app.toast.create({
      text: 'Hello, how are you?',
      destroyOnClose:true,
      on: {
        opened: function () {
          console.log('Toast opened')
        }
      }
    }).open();

  }
4

There are three reasons:

  1. Why do I have to do it that way when the docs say I can use an existing element?
  2. At some point, all that html tucked into all those text: parameters becomes unmanageable.
  3. If you’ve ever sold a company to a big player (I’ve sold 5), one of the things they look for is code maintainability and all that embedded html is just a mess to document and maintain. Doing it that way is a good way to fail a code audit.
2 Likes
5

Thanks for the answer it was an experience in me.

6

Imagine this: You build a great app, Google walks up to you and wants to buy it for large sums of money but first you have to pass a code review conducted by an independent consultant (or worse, a google employee).

Since you’ve never been through a code review you really don’t know how to prepare for one and you fail it. When you fail it, all that google money goes flying out the window.

Here are some basic rules:
Rule 1: Document everything! If you can’t document it, it’s considered unreliable code.
Rule 2: Validate every variable before using it (Hungarian notation is a great help for this).
Rule 3: Validate every return from every function
Rule 4: Document every conditional, for loop or do while()
Rule 5: Never, ever, ever, ever inject code (html or otherwise) - you will fail immediately! (this is why putting html in the text: parameter is such a bad idea).
Rule 6: Never host or pull any part of your code base from a cdn. If the device is offline, you’re app is unusable/dead.
Rule 7: Document every error message including where it’s generated. Any programmer should be able to lookup an error message and know exactly what file to go to.

Now, do you think you could spend a weekend and get all of this done for any shipping app and the related server code? How about a full week? How about a full month?

Hint: Code reviews are generally done quickly so you don’t have time to fix anything and if you’re tied up with contracts and meetings, you won’t have time to fix everything anyways.

5 Likes