piljac1

I literally copy/pasted your code and it works. Your problem is likely elsewhere. For example, you might have no div with the #app id wrapping your nav tag. Also, depending on your Vue version, the way you declared your data might be wrong. For example, in Vue 2, the syntax you used is fine for components, but for the root instance you need to declare it that way :

data: {
  isSticky: false,
},

Then you should ditch eager loading and use joins instead to gather all data you need to transform.

Then you should ditch eager loading and use joins instead to gather all data you need to transform.

I'd say using a full name attribute like @tray2 proposed is pretty standard. We use it in all our Laravel projects that have such needs.

Eager loading uses subqueries and not joins. That's why you can't do it that way.

Not sure if it has nothing to do with this, but having a script tag with a src attribute as well as content between the opening and closing tags is not HTML 5 compliant and is interpreted differently on each browser.

The query logic itself looks fine. Have you validated the content of auth()->user()->referred_by and matched it against all affiliate_id values in your database to see if it exists?

Also, you should use first() instead of get() to retrieve a single entry because after your query you're accessing the id property as you were expecting a single entry to be fetched.

I think it would be, because that would imply that a user could have many hobbies, but these hobbies should be unique/distinct. This means that if two of your users play hockey, you will have two "hockey" hobbies instead of just one that is linked to multiple users.

@fylzero Big RIP...

Cool photo change btw 😎

Every performance question can be answered by "It depends".

In your case, it mostly depends on your use case and your data pool. If you you don't expect to have a lot of data, you probably won't encounter a major performance issue BUT querying hobbies to sort users or collect any type of information will be a real pain in the ass.

So the short answer is: it depends.

The "long" answer is: I agree with @tray2 and you should use a many to many relationship. It offers a way better usability and scalability.

This is a perfectly normal and intended behavior

v-model will ignore the initial value, checked, or selected attributes found on any form elements. It will always treat the Vue instance data as the source of truth. You should declare the initial value on the JavaScript side, inside the data option of your component.

Now, I've never worked with a mix of Blade and Vue in the same template (other than rendering a Vue component in a Blade file), so I don't know what would be the best way to achieve this, but since the root Vue instance don't accept props which is the go-to solution when using components, you could instead add a data attribute to your Vue root div, fetch that data attribute value on the JS side and assign it to your roleType data property.

Never used the Google Charts API myself but on top of my head after reading the doc diagonally, I see some things that seem wrong.

1. If you get a "not defined" error, it means the library hasn't been properly imported. According to Google Chart's doc, you should have this in your head section (before your compiled scripts).

<script src="https://www.gstatic.com/charts/loader.js"></script>

If I'm not mistaken (sorry I'm a bit rusty), you won't have access to the google variable inside Vue. If that's the case, you should add the following script after the previous and referer to window.google in your Vue component instead of just google:

<script>
  window.google = google;
</script>

Alternatively, you could also use the google-charts npm package if you encounter any other issues.

2. You don't use a loader and a loader callback as specified in the doc. You should do something like this so when the component is mounted, the loader is :

mounted() {
  // Or window.google if you set it that way as stated in 1.
  google.charts.load('current', {packages: ['table']}); 
  google.charts.setOnLoadCallback(this.drawChart);
}

3. You shouldn't try to output drawChart() in your template. Instead you should have a div with an ID matching what you specified in your drawChart method

<div id="chart_div"></div>

Alternatively, you can also use Vue $refs which would be the Vue'ish approach.

The query logic itself looks fine. Have you validated the content of auth()->user()->referred_by and matched it against all affiliate_id values in your database to see if it exists?

Also, you should use first() instead of get() to retrieve a single entry because after your query you're accessing the id property as you were expecting a single entry to be fetched.

My guess is that since objects are passed by reference in JS, you're trying to update your state in your sendspouseId method.

You call await this.treeRecord(); in your mounted lifecycle hook, which attributes the state reference to this.data. Then you call this.getTreeSpouse(); which does this.data = this.familyTree;. At this point, this.data is already a reference to this.familyTree and I think that's why you're getting an error. Your logic is trying to "alter" this.familyTree due to the reference contained in this.data.

I would use a getter (and then use mapGetters) or simply use this.familyTree without assigning it to any other variable (this.data).

Not sure what is the exact purpose here, but couldn't you call your output method in your created lifecycle hook?

I've used Vue a lot in my Laravel projects and never in my life I had to use .vue() in Mix. Always used .js(). What's the issue you're encountering with .js()?

It's hard to help you without seeing what's contained in your app.js file.

First, in master.blade.php, put your @stack('scripts') under your app.js script.

Second, make sur you have something like this in app.js

import Vue from 'vue'

// This makes Vue available outside of your app.js compiled script
window.Vue = Vue

Third, your defer attribute might pose a priority issue, so try adding defer to your example.blade.php script tags

Try removing your node_modules folder and run npm install. Then, try to run npm run prod again. There might be some conflicts in your modules.

It has nothing to do with Vue itself. Your problem is JavaScript related. You're missing your accumulator's base value, since you want it to be an array.

return response.data.reduce((Accumulative, current) => {
   Accumulative.push({ value: current.id })
   return Accumulative
}, [])

However, wouldn't map be more appropriate for the task ?

return response.data.map(result => ({ value: result.id }))

It has nothing to do with Vue itself. Your problem is JavaScript related. You're missing your accumulator's base value, since you want it to be an array.

return response.data.reduce((Accumulative, current) => {
   Accumulative.push({ value: current.id })
   return Accumulative
}, [])

However, wouldn't map be more appropriate for the task ?

return response.data.map(result => ({ value: result.id }))

Why don't you use a variable to store the current active navbar item and update it each time you click on a navbar item. Use that variable to determine which item should have an active class. Then, in your created hook, you could set that variable based on the current hash.

// In your template section
<a
  :class="{ active: activeNavbarItem === 'home' }"
  href="#home"
  @click="activeNavbarItem  = 'home'"
>
  Home
</a>

// In your script section
data() {
  return {
    // ...
    activeNavbarItem: null
    // ...
  };
}

created() {
  this.activeNavbarItem = window.location.hash || null;
}

How about you add a v-if to your slider component which checks if your API data is not empty? That way, the component will only be rendered when the API data has been fetched.

My guess is that some dependencies were installed when you ran npm run dev. If that's the case, you shouldn't see this message anymore because they're now installed. It asks you to run it again to make sure everything gets compiled correctly by using the previously missing dependencies.

Both seem good. It is a question of personal preference. For me, the second option is more readable.

P.S. You can omit Carbon:: in option 2.

$schedule->command('reminder:every2weeks')->mondays()->when(function () {
    return now()->weekOfYear % 2 == 0;
})->at('10:00');

Why exactly do you need your API data to be fetched before the mounted lifecycle hook occurs? That kinda goes against the purpose of lifecycle hooks. My guess is that whatever you're trying to achieve, there is most likely a way to do it without trying to alter lifecycle hooks. So, what exactly are you trying to achieve?

Both seem good. It is a question of personal preference. For me, the second option is more readable.

P.S. You can omit Carbon:: in option 2.

$schedule->command('reminder:every2weeks')->mondays()->when(function () {
    return now()->weekOfYear % 2 == 0;
})->at('10:00');

There's no need to remove package-lock.json in this case. It's actually not recommended because it is what locks your versions into place to have a consistent environment everywhere.

You have to main ways to fix the error:

1. Install cross-env

npm install --save-dev cross-env

1. Remove node_modules, then run npm install (don't remove package-lock.json in the first place).

If both options don't work, you can try option 2 while removing package-lock.json before running npm install, but that's the last resort.

Oh well @michaloravec was quicker than me typing on my cellphone haha.

How about

Country::whereHas('states.students', function ($query) use ($universityId) {
    return $query->where('university_id', $universityId);
})->get();

That's assuming you have a $universityId variable, but you can use $this->id without the use statement if you're in your University model.

Disclaimer: my reply will not answer the OP's question directly, but will help him if he thinks about using one of the following.

OctoberCMS is a programmer-first CMS. Its UI and customization options are not "regular" user friendly. If the OP is going to manage the website himself, it probably wouldn't be an issue, but I would never let a customer close to their admin panel. It also uses Twig as a templating engine which takes you out of what you're used to when using Laravel (Blade).

On the other hand, you have Statamic, which has a beautiful UI and good UX (wouldn't say great because it has some issues). HOWEVER, I personally think V3, which is based on Laravel, has way too many flaws at the moment to be considered (especially if you need a multi-locale site). It is based on Laravel, but its base workflow is not close from Laravel at all. It uses their own templating engine called Antlers, which I totally dislike, because its parser is flimsy, it has bugs and is incomplete. For example, it has no assignment capability compared to Blade where you can use and affect php variables. Don't get me wrong, it is often considered bad practice to do assignment in templates, but it can useful for some specific cases (you can see Jeffrey using that feature a couple of times) and it sucks that Antlers doesn't offer anything for such cases (compared to Twig and Blade which do). You can use Blade instead of Antlers if you want, but it has poor integration within the CMS. Other than it's templating engine, it has a good amount of bugs and doesn't offer popular features such as nested taxonomies. That being said, I think it has really good potential, which is why I contribute for some features, but I wouldn't recommend it as of today.

A more "integrated" alternative which is not a CMS itself but and admin panel is Laravel Nova. I'll keep it short because I was a bit extensive with my Statamic impressions. Basically Nova is great if you stay within their "mold". The minute you need to code something that they don't support natively, you might have to fight with the package using some nasty workarounds. In the end, you can still make it work though. Since it's not a CMS like OctoberCMS and Statamic, you woukd have to code everything related to your "front-end" website from scratch (like a regular Laravel application).

My guess is that some dependencies were installed when you ran npm run dev. If that's the case, you shouldn't see this message anymore because they're now installed. It asks you to run it again to make sure everything gets compiled correctly by using the previously missing dependencies.

Update: Memory exhaust errors should now be resolved by using Composer 2. However, some of your packages might not be compatible with Composer 2, so you will have to be careful and resolve your packages compatibility errors after upgrading to Composer 2.

You can read the upgrade guide here.

Just a side note to @sinnbeck answer: his answer will ignore all leads that doesn't have the Email key defined. If you also want to validate that the value isn't falsy (null, false, empty string or 0 for example), you could use empty instead of !isset, but that decision will be based on your business logic.

An other thing to note is that you can pass multiple variables to the isset function and if one of the variables isn't set, the function will return false. This isn't true for the empty function though, which only accepts one parameter.

That explains your error. It tries to get a value from a key that isn't defined. If your email is nullable in your database and you couldn't care less if it's null, you could add the null coalescing operator in your create. That operator evaluates the left side expression and if it's not set or null, it falls back to the right side expression. In the following example, the fallback value is null, but it could be '' or anything you desire.

collect($leads)
    ->each(function ($lead, $key) {
        Lead::create([
            'email'         => $lead['Email'] ?? null,
            'first_name'    => $lead['FirstName'],
            'last_name'     => $lead['LastName'],
            'phone'         => $lead['Phone'],
            'agent_email'   => $lead['custom_fields'][2]['value'],
            'agent_name'    => $lead['custom_fields'][3]['value']
        ]);
    });

You can do the same for other nullable columns

That explains your error. It tries to get a value from a key that isn't defined. If your email is nullable in your database and you couldn't care less if it's null, you could add the null coalescing operator in your create. That operator evaluates the left side expression and if it's not set or null, it falls back to the right side expression. In the following example, the fallback value is null, but it could be '' or anything you desire.

collect($leads)
    ->each(function ($lead, $key) {
        Lead::create([
            'email'         => $lead['Email'] ?? null,
            'first_name'    => $lead['FirstName'],
            'last_name'     => $lead['LastName'],
            'phone'         => $lead['Phone'],
            'agent_email'   => $lead['custom_fields'][2]['value'],
            'agent_name'    => $lead['custom_fields'][3]['value']
        ]);
    });

You can do the same for other nullable columns

If you dd your $data['contacts'], do you see one or more entries where the Email key/value is not set?

Can you show your getLeads function code please?

Still on 1 at the moment because our main project is still running on older packages that are not compatible with composer 2. We're set to upgrade everything in a sprint or 2 (including a Laravel 6 to 8 upgrade).

I don't know if you meant that you set your php.ini memory_limit to -1 or composer's. If you meant that you tried setting it in your php.ini and not composer, you can prefix your command by COMPOSER_MEMORY_LIMIT=-1 which removes the memory limit for the current command. It always does the trick for me.

For example

COMPOSER_MEMORY_LIMIT=-1 composer update

Normally, it is the same as setting it in your php.ini directly, but for some reason, your changes might have not been picked up (i.e. you didn't restart your php service).

Depending on what else you want in your table, you can create a JSON column in your MySQL database table.

// In a migration file
$table->json('your_column_name');

Not sure if that wat the answer you were looking for though.

I don't know if you have already worked with React, but in my personal opinion I think Vue is a lot simpler because it implies more "magic". That of course excludes the new Vue composition API which is really close to React. All the conditional stuff. looped stuff and marginal things you see in any programming language is really easy to do with Vue. That being said, you will most likely need to know the basics of ES6 JavaScript to keep up. For references, of course you can Google, but Googling often doesn't make you efficient.

To summarize, no you don't "need" to know vanilla JavaScript inside-outs, but knowing them really well will make you much more efficient and will improve your global understanding of what's going on.

For example, if you never used a skateboard, you'll be able to use its basic feature the first time (rolling), but for anything more advanced, you'd have to look up online and practice over and over again. This is the same concept.

I haven't watched this particular Vue 2 series, but Vue 3 isn't much different than Vue 2 except a new optional syntax that ressembles React hooks and a couple of syntax/usage improvements. The main syntax/usage improvements are:

• No need to have a single root component in a template
• It is possible to teleport components without the use of a third party library such as portal-vue
• Reactivity on array and objects is improved
• You can now have multiple v-model on a component

On top of my head, these are the biggest changes.

My guess is that you get no authenticated user because API routes (api.php) are stateless and by the looks of your URL (which starts by /api), you probably declared it there. That means your session from routes declared in web.php (which are stateful) is not shared. If you want a stateful route, move it to web.php (and prefix it with /api if you want to keep the same URL).

Of course :)

There is an eloquent method, but he's saying that createOrUpdate is not a "valid" CRUD route.

Why not simply manage that logic in JS ? If your id is defined in the object, call the update route, else call the store route.

Yes, if you set a name on inputs and submit it, values will be received the same way than a normal HTML/PHP form.

It is very simple. Depending on what exactly you want to do (lock the user until revised, send an email, etc.), you can use a cron job that runs daily which compares today's date with the last time each user has been revised. If the revision timestamp column is null, compare with the created_at timestamp.

So for example, if you want to lock a user account, you could create a migration that adds a boolean field, for example revision_required that defaults to 0, but is set to 1 yearly. You could also add a revised_at timestamp to compare with today's date. If it's been a year since it's been revised, send an email to admins and set revision_required to 1.

Of course, this is a base idea to get you started. You can tweak it as you wish :)

I haven't watched this particular Vue 2 series, but Vue 3 isn't much different than Vue 2 except a new optional syntax that ressembles React hooks and a couple of syntax/usage improvements. The main syntax/usage improvements are:

• No need to have a single root component in a template
• It is possible to teleport components without the use of a third party library such as portal-vue
• Reactivity on array and objects is improved
• You can now have multiple v-model on a component

On top of my head, these are the biggest changes.

Man... You gotta help us a bit and post some code...