piljac1

The best comparison I can think of is the following: Inertia is like a car, it will get you from point A to point B, but if you want a better experience along the way, you're gonna have to add optional features.

Inertia is meant to simplify SPA implementation by "automating" XHR requests to load pages (Inertia::render(...)), but you can add separate calls to improve the UX. As it has been mentioned in the past by the creator himself: "You can always drop down to making plain XHR requests for some parts of your app if Inertia requests don't make sense".

Not sure about what they use, but Chart.js is excellent.

Is this thr only error .essaie you get or you have more info? Like a stack trace or something.

If anything, what is growing right now is Blazor. However, it won't ever be as popular as any technology/framework based on a "free" language, because it is in C#.

I don't know the exact context, but you're totally right. However, I'll add an asterisk.

This forum goes both ways. On one side, you have the "askers" and on the other you have the "answerers" (people can be both, but normally there's a side that is more popular). Askers get the benefit of having other people helping solve their problem. On the other hand, answerers receive gratitude, which is normally expressed by a like and/or a best answer.

These are the ideal cases, but both sides sometimes go out of their way. For example, an asker can lose its patience and express it in forms of passive-aggressiveness or straight up disrespect. People are here to help, for free, so the least you owe them is politeness and gratitude. On the other end, I think answerers genuinely want to help others, but sometimes, their desire to up their score comes into play, which may result in the same way, and it's not ok.

I personally am mostly an answerer. I am proud of it because I get to help others and refine my knowledge (win win right!). However, I would be hypocritical if I told you it never hit me when I genuinely believe I gave the best answer and someone else would get it by saying the exact same thing after me, or when the asker himself marks his own answer which states exactly what I said as the best answer. Still, that doesn't give me the right to rant about what I think, because it's my own personal opinion and the only real goal is to help the person in question.

Sorry for the long explanation, but I hope you understand my point haha.

Did you validate that you actually had a public/css/default.css file? If you have one, open your devtools and check your "Sources" tab. Open the css  folder and click on default.css, do you see all your CSS classes (use Cmd + F to search)? Else, what do you see?

I didn't alter my suggestion, which is weird.

But it looks like your user/group setup was not done properly. Look at the following, which will most likely help you fixing these permission errors : https://stackoverflow.com/a/37266353

I have never used Docker or Sail, so I can't help you with that unfortunately... Hopefully someone else can.

You can check out the following config. However, I wouldn't define "xdebug.start_with_request = yes" as it is recommended by Xdebug's creator to avoid doing so, because it will slow down your applications if you do not need to debug (you should use the appropriate Chrome, Firefox or Safari extension to activate debugging). Your problem is probably due to the fact that xdebug.start_with_request has a value of yes and/or that your IDE key has not been defined. If I recall correctly, you will get the error you have right if xdebug.start_with_request is set to yes, but if you don't define your IDE key, Xdebug won't work if you start the listener and run a command that has a breakpoint somewhere in its execution (breakpoint is never hit).

You're right, I thought it was in a class, I missed the part where he said it was in a controller. Either way, I don't think you should have that kind of logic directly in your blade. It should be in the appropriate model or class.

You should either alias it like @michaloravec suggested, or if you want better autocompletion (at least on VS Code), you can add this to the top of your file

use Carbon\CarbonInterval;

or prefix the namespace on the code line if it's a one time thing.

You can use CarbonInterval and convert it for humans. The cascade method converts seconds to days, hours, minutes.

CarbonInterval::seconds($duration['time_spent'])->cascade()->forHumans();

I didn't alter my suggestion, which is weird.

But it looks like your user/group setup was not done properly. Look at the following, which will most likely help you fixing these permission errors : https://stackoverflow.com/a/37266353

What are you Xdebug settings (in your php.ini or any other .ini file you used to define those)?

I 100% agree, but it's not like you're running it on a global npm install. It can be used to debug step by step. If everything runs fine, you can remove the node_modules folder and reinstall them properly without sudo, and then adjust permissions properly.

What happens if you run this yourself:

sudo npm install vue-template-compiler --save-dev --production=false

Does it work ?

If you access $shareSettings in your view, you want to use compact('shareSettings') or ['shareSettings' => $shareSettings]:

$response = $this->get('/', compact('shareSettings'));

If you access $shareSettings in your view, you want to use compact('shareSettings') or ['shareSettings' => $shareSettings]:

$response = $this->get('/', compact('shareSettings'));

Have you tried without @{{ }}?

Because text interpolation is not valid within a prop value. Look at my code and try it simply with :value="test"

Have you tried without @{{ }}?

Because text interpolation is not valid within a prop value. Look at my code and try it simply with :value="test"

If your test variable comes from Vue, can't you just do?

<input type="checkbox :value="test"> 

How about:

$companies = Company::select('companies.*')
    ->with('ratings')
    ->leftJoin('ratings', 'companies.id', 'ratings.company_id')
    ->where('name', 'like', "%{$name}%")
    ->groupBy('companies.id')
    ->having(DB::raw('AVG(ratings.rating)'), '>=', $request->rating_min)
    ->paginate($request->get('per_page', 10));

This will give you all companies that have an average rating over or equal to the specified minimum rating.

That's the rough idea, but you would need to tweak the logic a bit only include the leftJoin, the groupBy and the having when $request->rating_min is present.

P.S., don't forget to add use Illuminate\Support\Facades\DB; at the top of your file.

Also, if you don't need to access ->ratings on your individual models, you can take out ->with('ratings').

How about:

$companies = Company::select('companies.*')
    ->with('ratings')
    ->leftJoin('ratings', 'companies.id', 'ratings.company_id')
    ->where('name', 'like', "%{$name}%")
    ->groupBy('companies.id')
    ->having(DB::raw('AVG(ratings.rating)'), '>=', $request->rating_min)
    ->paginate($request->get('per_page', 10));

This will give you all companies that have an average rating over or equal to the specified minimum rating.

That's the rough idea, but you would need to tweak the logic a bit only include the leftJoin, the groupBy and the having when $request->rating_min is present.

P.S., don't forget to add use Illuminate\Support\Facades\DB; at the top of your file.

Also, if you don't need to access ->ratings on your individual models, you can take out ->with('ratings').

I thought you said companies had many ratings. In this test, there's a rating column in the companies table. Is that right or a mistake?

I think I might have understood. So given the example I posted above, a user could specify that the min average rating should be 4.4. In that case, Apple and Microsoft would show, but not Amazon?

Sorry, I don't understand what you're trying to achieve. Can you illustrate it with an example of what kind of input you will receive and what kind of output you're expecting?

By wanting to "filter companies according to the max rating and min rating", do you mean that you want to sort companies with the highest rating average descending ? For example:

Company     |   Rating
Apple       |   4.6
Microsoft   |   4.5
Amazon      |   4.2

Have you tried using the global search and search for the view path?

Or you can output this in your view:

{{ dd(request()->route()->getAction()) }}

There are only 3 reasons (on top of my head) that could make console.log "not work" :

1. You're trying to use console.log in the template section of the component. If that's the case, you need to create a method that will call console.log. Then you call that method from your template.
2. The section where you put your console.log is simply never hit.
3. You didn't compile.

P.S. if those 3 situations are not the cause, posting some code would help.

Can't you cmd + click on a method/class with PHP Intelephense? I'm pretty sure that you can.

At first, some fundamentals are hard to grasp, but after working on a couple of Vue projects, it becomes routine :). I get a week off starting on April 5th, so I'll probably spend a lot of time on Laracasts to help you and others out with future questions haha. I also had a feature idea in mind for Inertia, so I'll work on that to hopefully come up with a pull request that would bring a good benefit to the related stack.

Hi ! You're really close actually, but you have too many unnecessary elements.

First of all, you don't need $refs except if you have to interact with the element by using vanilla JS (useful to bind some third party library events).

Second of all, you don't need the value property because you can manage what (and how) you want to send data to your PUT/PATCH route which updates the child status.

There are minor fixes that can be applied, but for that, you can check out the sandbox I created. Of course, you shouldn't need the changedChild data property. I only used it to output what's happening visually. Also, I changed you href for # because it's just a test environnement. I also mocked some children because I don't have access to your API.

Basically, what you need to do is pass your current child as a parameter to the function you call on change. In my sandbox, I renamed the function to updateChildStatus, because that's probably what you're gonna do in that function. That being said, that's the syntax:

@change="updateChildStatus(item)"

Then you can accept the item as a parameter in your updateChildStatus method declaration. From there, manage the information to transform it as you wish and then PATCH (or PUT) it.

The best comparison I can think of is the following: Inertia is like a car, it will get you from point A to point B, but if you want a better experience along the way, you're gonna have to add optional features.

Inertia is meant to simplify SPA implementation by "automating" XHR requests to load pages (Inertia::render(...)), but you can add separate calls to improve the UX. As it has been mentioned in the past by the creator himself: "You can always drop down to making plain XHR requests for some parts of your app if Inertia requests don't make sense".

In theory you could do what you suggest and that would be the most UX friendy way. An easier way which might be a little less friendly would be to use Inertia manual routing or global Inertia listeners to show a spinner on the page when you click a button which redirects to another page. The spinner would occur as long as the entire page component is not rendered and then, when it is, it will show the entire requested page. It is not the same experience, but it is better than nothing and probably less of an hassle to implement. But as I said, the ultimate UX would be what you suggested, despiite the fact takes more time overall to implement (and requires additionnal routes/controllers).

Can you please post some code of what you tried?

That works, but I would reserve a more type checked implementation for the constructor. I would go through a static function which creates a new instance (passing parameters to the constructor). That way you also get better overall intellisense. The implementation you suggested still is type checked though, so it is still safe, just a level deeper.

The easiest way would be to have a static method named something like fromArray which accepts an array and convert it to properties. But there's no "out of the box" way.

Take care! 🙂

My solution may need some altering based on your date type (if it's not a string, the key should be converted to a string in the reduce part the logic to work). Also, I assumed that your date key name is "date". But basically, this is my solution (and here's a sandbox if you want to toy with it):

return Object.values(
  this.materialList
    .map((mat) =>
      mat.prices.map((price) => ({
        price: price.price * mat.pivots.percentages / 100,
        date: price.date,
      }))
    )
    .flat()
    .reduce((accumulator, price) => {
      const key = price.date;

      if (!accumulator[key]) {
        accumulator[key] = price;
      } else {
        accumulator[key].price += price.price;
      }

      return accumulator;
    }, {})
);

You might be like "woah there!", so here's what's going on:

• First of all, in the map portion, you iterate over each material and then map each prices into basically the same price structure, but with the price that has been multiplied by the percentages. At this point, this is what you get:

[
    [
        {
            "price": 3.9,
            "date": "2021-03-01"
        },
        {
            "price": 3.9,
            "date": "2021-04-01"
        },
        {
            "price": 5.1,
            "date": "2021-05-01"
        },
        {
            "price": 3.3,
            "date": "2021-06-01"
        },
        {
            "price": 5.7,
            "date": "2021-07-01"
        }
    ],
    [
        {
            "price": 2,
            "date": "2021-03-01"
        },
        {
            "price": 2,
            "date": "2021-04-01"
        },
        {
            "price": 2.6,
            "date": "2021-05-01"
        },
        {
            "price": 2.2,
            "date": "2021-06-01"
        },
        {
            "price": 2,
            "date": "2021-07-01"
        }
    ]
]

• Then, you can see that you have an unnecessary level of arrays, so then you call .flat() on that result, which gives you:

[
    {
        "price": 3.9,
        "date": "2021-03-01"
    },
    {
        "price": 3.9,
        "date": "2021-04-01"
    },
    {
        "price": 5.1,
        "date": "2021-05-01"
    },
    {
        "price": 3.3,
        "date": "2021-06-01"
    },
    {
        "price": 5.7,
        "date": "2021-07-01"
    },
    {
        "price": 2,
        "date": "2021-03-01"
    },
    {
        "price": 2,
        "date": "2021-04-01"
    },
    {
        "price": 2.6,
        "date": "2021-05-01"
    },
    {
        "price": 2.2,
        "date": "2021-06-01"
    },
    {
        "price": 2,
        "date": "2021-07-01"
    }
]

• With all prices at the same level, you can now use reduce to build an object keyed by the price date. If no key matches the date, create a new property with the date as the key and the entire price object as the value. Else, if there is actually a key matching the date, simply increment its price by the currently iterated price object's price. That gives us the following object:

{
    "2021-03-01": {
        "price": 5.9,
        "date": "2021-03-01"
    },
    "2021-04-01": {
        "price": 5.9,
        "date": "2021-04-01"
    },
    "2021-05-01": {
        "price": 7.699999999999999,
        "date": "2021-05-01"
    },
    "2021-06-01": {
        "price": 5.5,
        "date": "2021-06-01"
    },
    "2021-07-01": {
        "price": 7.7,
        "date": "2021-07-01"
    }
}

• Finally, you probably want the prices as an array for easier manipulation, so that's what Object.values does. And there it is, the final result:

[
    {
        "price": 5.9,
        "date": "2021-03-01"
    },
    {
        "price": 5.9,
        "date": "2021-04-01"
    },
    {
        "price": 7.699999999999999,
        "date": "2021-05-01"
    },
    {
        "price": 5.5,
        "date": "2021-06-01"
    },
    {
        "price": 7.7,
        "date": "2021-07-01"
    }
]

P.S. Of course you should probably round prices afterwards because floats are not 100% precise, so they can cause the problem you see on May 1st.

While I agree when you say to avoid building for the future, because YAGNI, I think there are cases where things can be made to be more future proof, without adding complexity (or extremely minimal complexity). In these cases, I think it can always be beneficial to plan for the future. In other cases when it adds a lot of development time and code complexity, don't bother.

As for tests, I think it's an ideal goal to strive for, but in some real world scenarios with limited budgets, they can unfortunately become a sacrificial goat. Like most of answers to programming related questions: it depends. It depends on the budget, the project lifespan, etc.

As for the current context. I don't consider model prefixing like a bad thing or code bloating if other models could share the same name (categories for example) without the same functionality. It can avoid a possibly big refactor (based on the project size) and if you didn't have the budget for code insurance (tests), you're saving yourself a headache.

Ideally I would use a front-end date library which would make your life a lot easier if you want relative dates. There used to be Moment.js, but it's now considered legacy by the dev team and they moved to Luxon, which is lighter, faster and immutable. If you use Luxon, there is a toRelative() method you can call on the date itself to get a really similar behavior than diffForHumans(). There is also Days.js which is extremely lightweight and offers a fromNow() method which is also similar.

In regard to this problem, I normally ask myself two questions. Let's take product categories for example:

1. Is it possible/logical that there could be other types of categories other than those related to products?
2. If so, could a polymorphic structure be used (without having unused columns in some contexts) to avoid creating multiple prefixed category tables?

If I answer "yes" to the first question and "no" to the second, I will prefix the table name, model and relations. Else, I won't prefix them.

Yes but watch out if you have tons of data, because you'll find yourself with a memory exhaust. Also, you will get worse performance than by ordering results on the database side.

I don't think there's a way without using join, but someone might surprise me haha.

Actions are asynchronous, which means there might be a delay before the mutation it dispatches is actually processed. {{ user }} doesn't throw any errors because it is valid regardless of its value. So even if user is null, it is valid. However, user.email is only valid if user is an object, which isn't always the case. When the application boots, the user is probably null (according to the error you're getting), so it's trying to access the email property on null. Then, it becomes an object, so now user.email is valid.

What you need to do is to add checks to validate the user is set before accessing one of its properties. What can also help is to use Lodash's get function which will not throw an error if the user is null.

What you could also do is to set {} as the user's default value instead of null.

My solution may need some altering based on your date type (if it's not a string, the key should be converted to a string in the reduce part the logic to work). Also, I assumed that your date key name is "date". But basically, this is my solution (and here's a sandbox if you want to toy with it):

return Object.values(
  this.materialList
    .map((mat) =>
      mat.prices.map((price) => ({
        price: price.price * mat.pivots.percentages / 100,
        date: price.date,
      }))
    )
    .flat()
    .reduce((accumulator, price) => {
      const key = price.date;

      if (!accumulator[key]) {
        accumulator[key] = price;
      } else {
        accumulator[key].price += price.price;
      }

      return accumulator;
    }, {})
);

You might be like "woah there!", so here's what's going on:

• First of all, in the map portion, you iterate over each material and then map each prices into basically the same price structure, but with the price that has been multiplied by the percentages. At this point, this is what you get:

[
    [
        {
            "price": 3.9,
            "date": "2021-03-01"
        },
        {
            "price": 3.9,
            "date": "2021-04-01"
        },
        {
            "price": 5.1,
            "date": "2021-05-01"
        },
        {
            "price": 3.3,
            "date": "2021-06-01"
        },
        {
            "price": 5.7,
            "date": "2021-07-01"
        }
    ],
    [
        {
            "price": 2,
            "date": "2021-03-01"
        },
        {
            "price": 2,
            "date": "2021-04-01"
        },
        {
            "price": 2.6,
            "date": "2021-05-01"
        },
        {
            "price": 2.2,
            "date": "2021-06-01"
        },
        {
            "price": 2,
            "date": "2021-07-01"
        }
    ]
]

• Then, you can see that you have an unnecessary level of arrays, so then you call .flat() on that result, which gives you:

[
    {
        "price": 3.9,
        "date": "2021-03-01"
    },
    {
        "price": 3.9,
        "date": "2021-04-01"
    },
    {
        "price": 5.1,
        "date": "2021-05-01"
    },
    {
        "price": 3.3,
        "date": "2021-06-01"
    },
    {
        "price": 5.7,
        "date": "2021-07-01"
    },
    {
        "price": 2,
        "date": "2021-03-01"
    },
    {
        "price": 2,
        "date": "2021-04-01"
    },
    {
        "price": 2.6,
        "date": "2021-05-01"
    },
    {
        "price": 2.2,
        "date": "2021-06-01"
    },
    {
        "price": 2,
        "date": "2021-07-01"
    }
]

• With all prices at the same level, you can now use reduce to build an object keyed by the price date. If no key matches the date, create a new property with the date as the key and the entire price object as the value. Else, if there is actually a key matching the date, simply increment its price by the currently iterated price object's price. That gives us the following object:

{
    "2021-03-01": {
        "price": 5.9,
        "date": "2021-03-01"
    },
    "2021-04-01": {
        "price": 5.9,
        "date": "2021-04-01"
    },
    "2021-05-01": {
        "price": 7.699999999999999,
        "date": "2021-05-01"
    },
    "2021-06-01": {
        "price": 5.5,
        "date": "2021-06-01"
    },
    "2021-07-01": {
        "price": 7.7,
        "date": "2021-07-01"
    }
}

• Finally, you probably want the prices as an array for easier manipulation, so that's what Object.values does. And there it is, the final result:

[
    {
        "price": 5.9,
        "date": "2021-03-01"
    },
    {
        "price": 5.9,
        "date": "2021-04-01"
    },
    {
        "price": 7.699999999999999,
        "date": "2021-05-01"
    },
    {
        "price": 5.5,
        "date": "2021-06-01"
    },
    {
        "price": 7.7,
        "date": "2021-07-01"
    }
]

P.S. Of course you should probably round prices afterwards because floats are not 100% precise, so they can cause the problem you see on May 1st.

Have you tried explicitly setting a position (relative, absolute, fixed, etc.) on your nav tag? Because specifying a z-index doesn't have any effect if you didn't explicitly specified a position.

Hi ! You're really close actually, but you have too many unnecessary elements.

First of all, you don't need $refs except if you have to interact with the element by using vanilla JS (useful to bind some third party library events).

Second of all, you don't need the value property because you can manage what (and how) you want to send data to your PUT/PATCH route which updates the child status.

There are minor fixes that can be applied, but for that, you can check out the sandbox I created. Of course, you shouldn't need the changedChild data property. I only used it to output what's happening visually. Also, I changed you href for # because it's just a test environnement. I also mocked some children because I don't have access to your API.

Basically, what you need to do is pass your current child as a parameter to the function you call on change. In my sandbox, I renamed the function to updateChildStatus, because that's probably what you're gonna do in that function. That being said, that's the syntax:

@change="updateChildStatus(item)"

Then you can accept the item as a parameter in your updateChildStatus method declaration. From there, manage the information to transform it as you wish and then PATCH (or PUT) it.

I've been working a lot of overtime in the past 3 weeks, so I'll blame what happened on the fatigue haha.

I feel like a f***ing dumbass right now, I tried adding SESSION_LIFETIME in my .env when debugging initially, but that's the problem: I added SESSION_LIFETIME when it was already existent lower in my .env.

Sometimes when you think your bug is way deep, it's probably because you're looking way too deep. Benefiting from other people's thought process often solves the issue in a hurry, and that's what happened. Thanks a lot!

Shame on me!

Hi guys! I'm having a somewhat big problem right now. Apparently, you can set the session lifetime in config/session.php by changing the lifetime value (which is in minutes) directly or via the SESSION_LIFETIME env variable. By default, it is 120 minutes and I can see that clearly when inspecting by cookies in Chrome. The Expires / Max-Age date time is two hours after my last activity. However, I tried to increase and decrease the lifetime config value (directly and via the .env file), but it always remain 120 minutes when I look at the Expires / Max-Age date time.

Here's the steps I took when changing the lifetime value :

1. Change the value
2. Run php artisan config:clear
3. Clear cookies inside the browser (Chrome) Application panel
4. Refresh the page.

I also bumped the session.cookie_lifetime and session.gc_maxlifetime as I found in a StackOverflow thread, but it didn't do anything.

Thanks in advance guys!

P.S. Here's my current lifetime config (which doesn't work as intended, it remains 120 minutes)

/*
|--------------------------------------------------------------------------
| Session Lifetime
|--------------------------------------------------------------------------
|
| Here you may specify the number of minutes that you wish the session
| to be allowed to remain idle before it expires. If you want them
| to immediately expire on the browser closing, set that option.
|
*/

// 1 week lifetime
'lifetime' => env('SESSION_LIFETIME', 10080),

'expire_on_close' => false,

Additionnal info : The expire_on_close config works as expected.