Yii2: Drop PJAX

[samdark]

• [x] Remove PJAX itself.
• [x] Remove PJAX-specific headers usage.

[Renkas]

Any alternatives? Should implement this myself if I want to use in 2.1? Move it to an extension maybe?

[samdark]

You can use the library directly. If you want to convert 2.0 PJAX into extension and support it, we'll link to it from the UPGRADE.

[bscheshirwork]

what the diff between clear PJAX and yii2-pjax?

buildin widgets will be work with clear pjax directly? like JQuery?

[samdark]

There will be no builtin widgets for PJAX.

[sniper888]

Why did that make a decision?

[samdark]

1. Too many problems with it. We have to patch the library.
2. It's not what current JavaScript trends are.
3. Yii is a PHP framework so we should focus on PHP and PJAX takes too much time to fix it.

[papppeter]

Hi,

could you maybe consider to drop it in favour of https://github.com/MoOx/pjax ?
so we still have this nice functionality.

[samdark]

Nope. Won't do it out of the box. It is decided. See above.

[klimov-paul]

Resolved by commit 603c084

[githubjeka]

Check checkboxes above ;)

[schmunk42]

For the record, there's also https://github.com/turbolinks/turbolinks - might be an alternative for some PJAX features

[SilverFire]

No more mighty JS libs, please :)

[bscheshirwork]

we need propose a alternatives... may be js-guru tell about usage pure pjax library instead yii2-pjax

[FabrizioCaldarelli]

I think that a modern php framework should provide packages and libraries to speed up also ui development (it has been done adopting bootstrap). So, I can be agree to remove pjax implementation from core, but changes regard also framework implementation (see pjax request handling insideYii). Although I could create an extension to replace currently pjax implementation (packaging current extension inside another extension), will that continue to work also with changes made inside Yii?

[bscheshirwork]

@FabrizioCaldarelli

(packaging current extension inside another extension)

another extension is a pure pjax?

[FabrizioCaldarelli]

My question is:could it possible to keep handling pjax request inside the code, so the only thing to do is creating an extension to use on Yii? I have a lot of pjax code and It will break after upgrading to 2.1,without a fast solution.

[bscheshirwork]

+1
We need a external tool same at current in-box tool; This is important.

[samdark]

No. We won't keep it. It it entirely possible to handle standard request-response in PJAX-manner w/o any extra modifications to the framework itself.

[rugabarbo]

@bscheshirwork
If you need it you can create extension for 2.1 and share it using github.

[bscheshirwork]

It it entirely possible to handle standard request-response in PJAX-manner w/o any extra modifications to the framework itself.

So... Anyway. We need a instruction about this. So many people use in-box pjax

step by step instruction for migrate to pure pjax from yii-pjax.
like

1. Change all of pjax::begin() to "example code here" and pjax::end() to "example code here"
2. add 'css-class' to enabled
3. add 'pjax-disabled' to disable in link inside container

[FabrizioCaldarelli]

@samdark I see that in 2.1 it has been removed much code in Request that recognize pjax Request. So if I create a new extension, Yii will not distinguish get/post request from pjax request. Is it right?

[samdark]

Yes. That is correct.

[FabrizioCaldarelli]

So should the new extension apply a path to Yii code adding again the same code that has been removed? Is it possibile to keep at least Request code in Yii? Otherwise we have to rewrite the same code

[FabrizioCaldarelli]

My curiosity. Removing Pjax we lose real time interaction, coming back to full page reload (90s years style). What should be the modern js approach to give a real time appeal to frontend ui? For example, how will grid view refresh work without pjax? Full page reload?

[schmunk42]

The vast majority of the removed code belonged to the Pjax widget and asset. Those can be replaced with an extension.

For mimicking Request::getIsPjax() a behavior could help.

[FabrizioCaldarelli]

I'm agree to keep as clear as possible Yii core, but I'm thinking at all index.php files that contain GridView wrapped by PJax by default. I've many projects that by default have GridView inside a Pjax, to take advantage of updating of a single part of view.
So switching to 2.1 version that files will not work anymore, and I think that many other people will be in this situation.
Can we think to a softer approach? Also to keep native app appeal that avoid full refresh of page when gridview update (filtering, changing page, etc.. etc..).

[FabrizioCaldarelli]

@samdark How will GridView work by default, after removing Pjax? Full page reload? Alternatives?

[schmunk42]

So switching to 2.1 version that files will not work anymore, and I think that many other people will be in this situation.

If there'd be an extension yii2-pjax which would give you the Pjax widgets (with an aliased namespace?), what would not work in your opinion?

@yiisoft/core-developers What's about creating a repo in https://github.com/yiisoft-contrib for yii2-pjax?

[FabrizioCaldarelli]

@schmunk42 I think that we need to keep handling pjax inside Request class, to avoid to add a behaviour or a change to Request flow.
If we keep that, then we can split Pjax in an extension, keeping the same namespace if possible. So switching will be completely transparent.

[FabrizioCaldarelli]

@schmunk42 But until now I can't figure how replace Pjax UI behaviour with some other alternative. What do you think about it? How will you reproduce same appeal of Pjax (for example, refreshing gridview), without a full page refresh?

[schmunk42]

@FabrizioCaldarelli This is the PJAX part of Request - https://github.com/yiisoft/yii2/blob/2.0.14/framework/web/Request.php#L465-L472

What else do you think of?

[FabrizioCaldarelli]

@schmunk42 Also in this:
https://github.com/yiisoft/yii2/blob/2.0.14/framework/web/Response.php#L854-L857

[schmunk42]

Maybe the Request/Response code could stay, there is also handling of edge cases like X-Ie-Redirect-Compatibility. Having those checks and features would not hurt - for around 10 lines of code, IMO.

[FabrizioCaldarelli]

Exactly, I think that leaving that code will not impact anything.

[schmunk42]

No. We won't keep it. It it entirely possible to handle standard request-response in PJAX-manner w/o any extra modifications to the framework itself.

@samdark Keeping the code or do you have an idea how to do the Response stuff?

[bscheshirwork]

we need to keep handling pjax inside Request class

may be we need use closure for it?

[samdark]

X-Redirect is still there since it's common. PJAX-specific headers handling won't be in the core since it's that library only specific header.

[schmunk42]

But is X-Ie-Redirect-Compatibility not highly specific for Internet Explorer?

Will be or is threre a way to post-process the Response in Yii 2.1?

[samdark]

Maybe.

[FabrizioCaldarelli]

@samdark so gridview is planned to use full page reload to filter and to navigate the pages?

[samdark]

Out of the box — yes.

[FabrizioCaldarelli]

In a previous comment you refer that pjax does not follow js trends. What are last js trends?

[samdark]

Something like MVVM. https://vuejs.org/, https://reactjs.org/, https://angular.io/.

[schmunk42]

What are last js trends?

Developing a new trendy framework every half-a-year or so :speak_no_evil:, which makes it pretty hard to follow the latest trends :stuck_out_tongue_winking_eye:

[samdark]

Yes, that :) Everything's changing too fast so it makes no sense to try to tightly integrate anything advanced from JS world. Basic things are OK though.

[FabrizioCaldarelli]

@samdark It could be good to create an official yii2-pjax repository to put all deleted sources from core. So the extension would refer officially to Yii2, instead using personal repository.
If you think that it is wrong, I could create a personal extension for this.

[SilverFire]

Would you like to support this repo?

[FabrizioCaldarelli]

@SilverFire Yes. I think that Yii should continue to support Pjax.

[samdark]

Core team won't support it for sure. If you want to take care of it, please create an extension and we'll link to it from upgrade notes.

[FabrizioCaldarelli]

Ok, it is clear. Because I understood that it is planned to split ui and js libraries from core, do we want to define a base namespace for all these (and future) extensions? Could it be yii/ui/,,, or similar? Instead creating all extensions with owner and different namespace.

[samdark]

Different namespace is fine. Since it won't be yiisoft-maintained library, it's not a good idea for its namespace to be \yii\*.

[albertborsos]

I have just made an extension for the pjax widget.
https://github.com/albertborsos/yii2-pjax

[bscheshirwork]

So... Also we can use origin pjax https://github.com/defunkt/jquery-pjax;

This is asset for connect it
https://github.com/bscheshirwork/yii2-jquery-pjax-asset

[samdark]

GitHub switched to https://github.com/martndemus/pjax btw.

[bscheshirwork]

@samdark
I don't understand what you mean...
GitHub community use https://github.com/martndemus/pjax
or some of my links is broken?

[samdark]

Nope. Just mentioned it that GitHub switched from jQuery to native JS for PJAX.

[bscheshirwork]

May be "GitHub" as "engine of site https://github.com"? This cool...

[omzy]

Why can't it just be made available as an official Pjax / client side JS library that we include in AppAsset.php, similar to how we do with BootstrapAsset?

[samdark]

That's what https://github.com/albertborsos/yii2-pjax is for.

[samdark]

These features will be enable-able via config. Composer config is still config.

[simialbi]

Maybe it would be a good idea to found some kind of organization maintaining yii-extension.
There could willing third party developers be members but all changes will be checked by yii team.

[samdark]

what USPs does Yii offer over other frameworks

1. Performance.
2. Gii.
3. AR and DB layers.
4. Documentation (especially phpdoc).
5. i18n
6. ...

[samdark]

but all changes will be checked by yii team

That's what we're trying to avoid to get more time for the core framework.